Document made available under the 
Patent Cooperation Treaty (PCT) 



International application number: PCT/GB05/001 148 
International filing date: 17 March 2005 (17.03.2005) 

Document type: Certified copy of priority document 

Document details: Country/Office: GB 

Number: 0406076.0 

Filing date: 17 March 2004 (17.03.2004) 



Date of receipt at the International Bureau: 18 May 2005 (18.05.2005) 



Remark: Priority document submitted or transmitted to the International Bureau in 
compliance with Rule 17.1(a) or (b) 




World Intellectual Property Organization (WIPO) - Geneva, Switzerland 
Organisation Mondiale de la Propriete Intellectuelle (OMPI) - Geneve, Suisse 



PCT/GB 2DU5 / 0 u 1 i * « 




y The %> 

% Office I 
> T 



INVESTOR IN PEOPLE 



The Patent Office 
Concept House 
Cardiff Road 
Newport 
South Wales 
NP10 8QQ 



I the undersigned, being an officer duly authorised in accordance with Section 74(1) and (4) 
of the Deregulation & Contracting Out Act 1994, to sign and issue certificates on behalf of the 
Comptroller-General, hereby certify that annexed hereto is a true copy of the documents as 
originally filed in connection with the patent application identified therein. 



In accordance with the Patents (Companies Re-registration) Rules 1982, if a company named 
in this certificate and any accompanying documents has re-registered under the Companies Act 
1980 with the same name as that with which it was registered immediately before re- 
registration save for the substitution as, or inclusion as, the last part of the name of the words 
"public limited company " or their equivalents in Welsh, references to the name of the company 
in this certificate and any accompanying documents shall be treated as references to the name 
with which it is so re-registered. 



In accordance with the rules, the words "public limited company" may be replaced by p.l.c. , 
pic, P.L.C. or PLC. 

Re-registration under the Companies Act does not constitute a new legal entity but merely 
subjects the company to certain additional company law rules. 




Signed 
Dated 5 May 2005 



An Executive Agency of the Department of Trade and Industry 



- - '■ ■ • 



Patents Form 1/77 

\nis Act 1977 
v _ Jle 16) 



Patent • 



18HfiRQ4 E881958-1 B22858- 



Request for grant of a patent 

(See the nates on die back of this form. You can also get 
an explanatory leaflet from the Patent Office to help you Gil in \ 
this form) 



\ 7 MAR 2Q0H 

RULE 97 
NEWPORT 



JW7700 0=00-0406076.0 NONE 

Tlie Patent Office 

Cardiff Road 
Newport 
South Wales 
NP10 8QQ 



1 . Your reference 



2. Patent application number 

(The Patent Office will fill Wis part in) 



0406076.0 



MAR 2004 



3. Full name, address and postcode of the or of ^—e— >j a o> W- > — j-^l 

" each applicant (underline all surnames) 'cvAriS-^Wo \ C^fcD r \f-\ >•— I 



Patents ADP number (if you kno-w it) I — c^b^^C>^^ 

If the applicant is a corporate body, give the <?~TS ° ° V 

country/state of its incorporation LA - * 



4. Title of the invention 



5. Name of your agent Of you have one) 

"Address for service" in the United Kingdom 

to which all correspondence should be sent /\^> C^^r^cZ> f \J ^^ 
(including the postcode) 



Patents ADP number (if you know it) 



6 Priority- Complete this section if you are Country Priority application number Date of filing 

declaring priority from one or more earlier (if you knoro it) (day / — /year) 

patent applications, filed in the last 12 months. 



7. Divisionals, etc: Complete this section only if 
this application is a divisional application or 
resulted from an entitlement dispute (see note f) 



8. Is a Patents Form 7/77 (Statement of 

inventorship and of right to grant of a patent) 
required in support of this request? 
Answer YES if: 

a) any applicant named in part 3 is not an inventor, or 

b) there is an inventor who is not named as an 
applicant, or 

c) any named applicant is a corporate body. 
Otherwise answer NO (See note d) 



Number of earlier UK application Date of filing 

(day /month /year) 



yfe=s. 



Patents Form 1/77 



Patents Form 1/77 



} Accompanying documents: A patent application ' 
- must include a description of die invention. 

Not counting duplicates,. please enter the number 
6? pages of each item accompanying this form: 

Continuation sheets of this form 

Description eg 



Claim fs) ^ I 
Abstract j 
Drawings -^(^ 




10. If you are also filing any of the following, 
state how many against each item. 

Priority documents 

Translations of priority documents 

Statement of inventorship and right 
to grant of a patent (Patents Form 7/77) 

Request for a preliminary examination 
and search (Patents Form 9/77) 

Request for a substantive examination 
(Patents Form 10/77) 

Any other documents (please specify) 



11. I/We request the grant of a patent on die basis of this application. 

' l^wyWv^ ^-^S3>~ . Date j£ MA£0 



- 12. Name, daytime telephone number and 

e-mail address, if any, of person to contact in 



e-mail auwcM, u any, ox person to contact in _ -~ t O *P 

the United Kingdom ^ *\ * / ] \k^f<Z>\^> 



Warning 



After an application for a patent has been filed, the Comptroller of the Patent Office will consider whether publication or 
communication of the invention should be prohibited or restricted under Section 22 of the Patents Act 1977. You will be informed if it 
is necessary to prohibit or restrict your invention in this way. Furthermore, if you live in the United Kingdom, Section 23 of the Patents 
Act 1977 stops you from applying for a patent abroad without first getting written permission from the Patent Office unless an * 
application has been filed at least 6 weeks beforehand in the United .Kingdom for a patent for the same invention and either no direction 
prohibiting publication or communication has been given, or any such direction has been revoked. 

Notes 

a) If you need help to fill in this form or you have any questions, please contact the Patent Office on 08459 500505. 

b) Write your answers in capital letters using black ink or you may type them. 

c) If there is not enough space for all the relevant details on any part of this form, please continue on a separate sheet of paper and 
write "see continuation sheet" in the relevant part(s). Any continuation sheet should be attached to this form. 

d) If you have answered YES in part 8, a Patents Form 7/77 will need to be filed. 

e) Once you have filled in the form you must remember to sign and date it. 

f) Part 7 should only be completed when a divisional application is being made under section 1 5(4), or when an application is being 
made under section 8(3), 12(6) or 37(4) following an entitlement dispute. By completing part 7 you are requesting that this 
application takes die same filing date as an earlier UK application. If you want the new application to have the same priority date(s) 
as the earlier UK application, you should also complete part 6 with the priority details. 

Aug 03 Patents Form 1/77 



1 

A TRANSACTION MANAGEMENT SYSTEM AND METHOD 



Field of the invention 

The present invention relates to the field of online commerce. In particular it relates to the operation of 
5 electronic markets in which there are a plurality of sellers. 

Background of the invention 

Buying and selling online is conducted through a variety of mechanisms for matching the buyer and seller. 
These mechanisms include online catalogues, auctions, bid/ask systems, aggregating of buyers, request-for- 
1 0 quote services and bulletin board listings. Each mechanism is strong for certain types of transaction and weak 
for others. 

The mechanisms above can be divided between those that allow immediate purchasing of pre-determined 
goods or services and those that accommodate irregular purchase requests but require more time for a 
1 5 purchase to complete. 

An online catalogue of the type accessed at Amazon.com for example allows goods that have been described 
by the seller to be displayed to buyers at a price set by the seller. Similarly items auctioned on sites such as 
ebay.com are described by the seller but he then waits to see what price the market will pay for his offering. 
20 Bid/ask services such as that operated by Priceline.com and described in US patent 5,794,207 require buyers 
to define a specific item or range of items to be purchased, typically an airline ticket between two points in a 
given date range, then wait to see if that need will be matched from a seller's database of pre-described 
offerings. 

25 By contrast a buyer accessing a request-for-quote service such as that operated by guru.com is able to define 
his particular needs of the moment, a day of web design work at a specified location for instance, and then 
receive quotes from sellers who, having digested his requirements, quote a price at which they are willing to 
fulfil his need: This is time consuming for all concerned. Buyers must wait for a, range of sellers to reply to 
their request to be sure of a fair price. Sellers must take the time to understand buyers' requirements and bid, 

30 knowing they may not be successful in getting the business. 

The time consuming nature of online transactions in which the buyer is able to define his exact needs rather 
than shopping between various options pre-defined by sellers makes existing mechanisms impracticable for 
many transactions. They include short notice purchases or small purchases where the sum involved does not 
3 5 merit the attention of sel lers or the waiting of buyers. 

Ideally, in many markets, a buyer would wish to define his exact requirements of the moment and 
immediately be given a list of sellers specifically available and ready to meet that need. For instance his need 
might be "I want a temporary secretary to work from 2.00 to 6.00 this afternoon at my office". He would then 
40 wish to see an immediate list of sellers who were (a) qualified to work as secretaries (b) in the vicinity of his 



3 



15 



20 



25 



30 



office (c) willing to work this afternoon (d) currently willing to accept assignments at short notice (e) 
currently willing to accept assignments of only a few hours duration (f) could be contacted in time to receive 
details of this period of work. 



5 Existing mechanisms are of little use to such a buyer. A bulletin board for instance will reveal a list of 
possible secretaries who can be emailed to see if they meet the characteristics above. An auction would be 
too time consuming for the buyer who could more easily phone a temporary worker supply agency. An 
online catalogue that simply allows the buyer to browse a list of offerings is again too time consuming for 
this buyer. Bid/ask type services require the buyer to input the price he will pay rather than allowing a market 
10 rate to be established. 

To overcome this gap in the art the present inventor has previously disclosed elements of an online 
buyer/seller matching system called "OEMs" Such a system is defined by an ability to take in a buyer's 
requirements and immediately construct options specific to his needs based on broader inputs from any 
number of sellers. Any of these options can then be purchased immediately. Such a system could run a 
plurality of markets in different sectors, for example such markets might include: bicycle hire, hire of a 
driving instructor or short notice office cleaning services. 



35 



Fig 1. shows the buyer input screen for such a system as completed by a buyer who is seeking to book a 
temporary secretary. Fig. 2 shows the options returned immediately by such a system. These are not bulletin 
board style listings showing potential sellers who may possibly be available and possibly be interested in this 
transaction. They are specific options built around the buyer's inputs priced and ready for purchase. 

Such a system holds considerable information about each seller which can be searched in the light of a 
specific buyer's enquiry. Each seller displayed on the screen represented at Fig. 2 has previously specified 
parameters within which they are willing to Sell. These may include geographical area, period-of-notice for 
an assignment and length of assignment. This information is stored. All of those parameters are met by this 
requirement for each seller on the screen. The system has also checked that the seller is showing availability 
in an online availability diary this afternoon and that their diary of times when they undertake to be reached, 
for instance by mobile phone text message or email, would allow them to be notified of this transaction in 
time. The buyer can choose any one of these sellers and the system will inform the individual of the 
assignment regarding them as sold and making the required amendments to their availability diary. 

Aspects of the OEMs system have been disclosed in publications by the present inventor. An overview of one 
embodiment of such a system will now be provided to illustrate one form of underlying architecture for the 
present invention. Referring first to Figure 3, this shows a generalised embodiment 300 of a system that 
might underlie the present invention. Such a system would run a number of markets in different sectors, 
examples of sectors include: secretarial services, office rental and vehicle hire. 
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A Communications Network 303 is connected to Seller Terminals 301a and b and Buyer Terminals 302a and 
b and to a System Communications Interface 304. The communications network may comprise any 
conventional communications network such as a telephone network or the Internet. The communications 
network couples the buyer and seller terminals to the System Communications Interface 304 to provide user 
5 interfaces to the system to allow buyers and sellers to request and execute transactions using the system. 

The Communications Interface 304 is coupled to a Communications Processor 305 which creates screens and 
messages for communicating with buyer and seller terminals 302 and 301. The communications processor is 
connected to an Application Processor 306 for providing transaction management applications. Application 

10 Processor 306 is also coupled to a system service provider terminal 308 to allow a system service 
provider/operator direct access to aspects of the system to which access via Communications Network 303 is 
restricted for security reasons. Thus Service Provider Terminal 308 may be used for system management, 
account management, program code updating, setting a mark-up on each transaction within the system for 
operator revenue purposes and similar functions. In an alternative embodiment Service Provider Terminal 

15 308 may be connected through a wider communications medium such as the Internet. 

Application Processor 306 is coupled to Data Store 307 storing system-related data. It is also able to 
communicate with external servers that perform specific additional tasks for the benefit of system users. 
Thus Application Processor 306 can process data for output to buyer and seller terminals 302 and 301 and 
20 Communications Processor 307 can access the data to send and receive messages to and from terminals 302 
and 301. Thus data in Data Store 307 is indirectly accessible via buyer and seller terminals 302 and 301. 

The Communications Interface 304, Communications Processor 305, the Application Processor 306 and the 
Data Store 307 may all be provided within a single general purpose computer or these functions may be 
25 distributed over a plurality of machines in a manner well known to those skilled in the art. 

The Communications Network 303 in this embodiment is the Internet to which are coupled Buyer Terminals 
302a and b and Seller Terminals 301a and b. Also coupled to Internet 303 is a gateway (not shown) to a 
mobile phone network 309 (or, more generally, any mobile communications network) which communicates 
30 with a Mobile Station 31 1, such as a phone handset, using base transceiver station 310. 

Fig 4. illustrates a preferred embodiment for the system's architecture within a central server. 
Communications Processor 305 interacts with Communications Interface 304 to receive inputs and forward 
output communications to buyers and sellers. Application Server 306 contains software modules allowing 

35 new users accessing the system through the communications network to register as sellers 421 or buyers 422, 
or both. Transaction Management Module *423 extracts market rules information from the data store to 
govern information displayed to users in a particular market and the prioritization of searches. Assembly of 
Options Module 424 receives lists of relevant sellers after a search and applies rules on their filtering and 
display. In its simplest embodiment this module sends all sellers returned by the search to the 

40 Communications Processor 305. Price Construction Module 425 takes the list of sellers produced by 
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Assembly of Options Module 424 and constructs the unit price at which each seller will fulfill this buyer's 
specified needs. 

Once a buyer has selected a seller he wishes to purchase, Post Sale Management Module 426 compiles the 
information about the buyer and transaction that is required to inform the seller of all required details of the 
sale. Payment transfer module 427 ensures value is transferred from buyer to seller according to instructions 
in the market rules data store. This might involve credit card processing, transfer of digital value, holding 
sums in escrow or raising of an online invoice. It may entail breaking the transaction down into parts, the 
completion of each triggering part payment. Typically this could be achieved by means of atimesheet signed 
by buyer and seller using their system passwords at the end of each week of a booking. All these processes 
will be familiar to one skilled in the art and can be performed by widely available software. 

User Maintenance Module 428 applies rules to the seller and buyer data store as instructed through the 
Service Provider Terminal 308. These might include for instance generating email to any user who has not 
been active in the last 6 months asking that they confirm the email address, and therefore their identity,' is still 
valid. 
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The Data Store 307 comprises firstly a Database Of Sellers 431. For each seller this includes unique 
identifying code, name, password, date of birth, contact details, time and date of registration, unit price to be 
charged to buyers, history of transactions performed plus earnings and details of how payments are to be 
transferred. For each seller there is additional data stored which can be changed at any time by the seller to 
which it pertains. Selling Parameters Record 431a stores that seller's preferences for sales, for instance how 
far from their base travel code they are willing to travel. Seller Availability Record 431b stores data input by 
the seller about the times when they are available to be sold by the system. Seller Contactability Record 431c 
stores data of the times the seller undertakes to be available for contact by the system and the means by 
which messages should be sent. 

Buyer Database 432 includes information about each buyer on the system. This includes unique identifying 
code, name, administrator password, headquarters address, time and date of registration, details of other users 
within the buyer's account allowed to buy on its behalf (named members of staff for example), how 
payments are to be collected, history of transactions and payments made and the information to be displayed 
to sellers, for instance showing locations of the buyer's buildings at which they may be required to work. 

Transaction Database 433 records details of all transactions on the system. A preferred embodiment of this 
database includes the following record of any purchase or partly completed purchase: unique identifying 
code, market in which purchase was made, identity of buyer, identity of seller, time' purchase initiated, 
number of units bought (hours of work for instance), dates units were to be supplied, times of day units were' 
to be supplied, price paid per unit, selling parameters pertaining to this transaction and current status of the 
transaction which can be only one of the following exemplary list: waiting for seller confirmation / not 
40 confirmed/ confirmed / in progress / cancelled / completed. 
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Market Rules Database 434 stores information pertaining to each market sector. Wording and options 
required to make up screens or messages for the user are extracted by Communications Processor 304. 
Market Rules Database 434 also stores rules on admission to a market, for instance "only sellers over 18 
5 permitted" or "no more than 50 hours to be sold by any individual seller in one 7 day period". 

In the above-described aspects of the system communication between the system operator or intermediary 
and/or buyer and/or seller may be by any convenient communication means, but the system is particularly 
suited to implementation using an electronic communications network such as the Internet, and Intranet, or 
10 an Extranet, or wireless mobile communications. 

In preferred embodiments the system is implemented on general purpose computer systems using appropriate 
software. The software may comprise instructions in one or more of HTML, XML, Java, Perl or other 
programming languages. Thus aspects of the system may be embodied in computer program code, either as 

15 separate applications or parts of a single program. As the skilled person will appreciate, such program may 
comprise source, object or executable code and code may be implemented on a single machine or shared 
between different hardware platforms. Such program code may be provided on any conventional carrier 
medium such as tape, disk, CD-ROM, programmed memory or on an electrical or optical signal carrier. The 
processor implementable instructions of the buyer and seller terminals may be stored on a network server and 

20 provided to the terminal as needed, for example as an Internet data page or web page. 

Processes used in such a system will now be described. For ease of understanding the operation of the system 
will be described with reference to a specific example of the system's use, that of providing temporary 
secretaries to employers. However use of the system is not restricted to this application. 

25 

Listing goods or services to be sold 

A new seller will typically enter the system through a portal accessed via the Communications Network 303 
and constructed by the Communications Interface 304. This page is able to activate the Seller Registration 
Module 421. Having taken details of the individual or company, this module then offers a selection of 

30 markets in which anyone might register to sell. Thus a new seller might be asked "what do you wish to sell" 
and then offered a first selection list which includes "my time". This response prompts a second list from 
which she chooses "formal temporary work" and then "secretarial work". A seller can choose to sell in 
multiple market sectors. A seller may not be named as an individual but simply as "secretary from XYZ 
Agency". They are then invited to input the pricing data that allows their price for a transaction for which 

35 they are applicable to be constructed. In its simplest embodiment this requires only that they specify a flat- 
rate price for each unit of sale or part thereof. In the temporary work market the unit of sale is hours. 

Thus the system knows the individual's name, contact details, including email address and optional mobile 
phone number, and that she wishes to sell her time as a temporary secretary at, for example, $8.35 an hour. 
40 These details are recorded in seller database 431 . 
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At this point the Seller Registration Module 421 asks the questions that allow this user's parameters for any 
potential sale to be stored in the Seller Parameter Record 431a. A list of parameters relevant to sales in the 
secretarial market are accessed from the market rules database 434. They may include: 
5 Geography (for example: "My home postal code is X and I will not work more than Y miles from 

that point") 

■ Size of purchase (for example: "I will not accept bookings of less than 4 hours" or "I will .not accept 
bookings lasting more than 10 working days") 

■ Period of notice for purchase (for example: "I only accept bookings where I have at least 24 hours 
10 notice of the job") 

Additionally the seller may be able to define specific buyers registered^ the_BuyerJ3atabas^43_2.with_ 
whom they are unwilling to trade. This is recorded on the Seller Parameter Record 431a. 
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The new seller is then offered a blank diary of time blocks, possibly in half hour increments, covering each 
day for the remainder of the current week. She can click through to further pages covering following weeks. 
By selecting certain blocks she is able to select the precise times when she is available to work. This is stored 
in the Seller Availability Diary 431b. By default this diary remains blank with no availability until the seller 
has input details of her willingness to work. 

In a further embodiment the seller is now presented with a second set of diary pages and asked to input times 
when she undertakes to be contactable by the system. These are periods when she will be logged on to 
receive email or will have her mobile phone switched on and about her person to receive text messages. This . 
data is stored in the Seller Contactability Record 43 1c. 

Thus it will be clear that the Seller Database 431 now holds' details of the individual's identity (including 
password), market or markets in which they wish to sell, their unit price, the constraints on any sale they will 
accept, the times they are available to sell their chosen goods or services sold by the system and the times at 
which they can be contacted by the system. Any part of this information can be changed at any time by the 
seller logging on and triggering the User Maintenance Module 427. This will display current choices stored 
in the Seller's Parameter Record 431a, Availability Diary 431b and Contactability Record 431c. The seller 
can then choose to overwrite her current preferences. 

The above example pertains to a potential seller wishing to sell their time. It will be clear the architecture 
described could equally accept listings for other services. For example: load space on trucks, domestic 
storage capacity, sales of organic produce or childcare. In each case the Market Rules Database 434 would 
provide a list of relevant parameters to be completed by the seller. An example of the selling parameters by 
which sellers can define their willingness to sell based on a buyer's specific needs for some further markets 
will now be given. 
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MARKET 
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Overnight accommodation 


Night 


Length of stay / time of arrival / time of departure / 
number of people in room / smoker or non-smoker / 
period of notice to hire 


Hire of agricultural tractors 


Hour 


Distance to buyer / anticipated hours of work within 

+!~ip> Vnri=» / l^noth nfhirp / nprind nfnofidP to hire 
tne fine / icn^ui ui nno / jjgaiuu ui iiuu^w lvj nav 


Local deliveries 


Mile 


Period of notice to pick up / distance from seller 
postalcode to pick up point / length of journey / 
distance from seller postalcode to drop-off point / 
weight of object to be delivered / size of object to be 
delivered 


Specially commissioned 
home cake baking 


Kilogram 


Smallness of cake / largeness of cake / style of cake 
(selected from drop down boxes) / period of notice 
before delivery / delivery method / additional 
trimmings (selected from drop down boxes) 



The purchase process 

A new buyer accesses the system through Communications Interface 304 and is shown a generic welcome 
5 page generated by Communications Processor 305. From this the new buyer is able to trigger Buyer 
Registration Module 422. This sends pages requesting information, validates that information and uses it to 
populate a record in Buyer Database 432. Confirmation of the buyer's means to pay may be obtained through 
a link to an external agency such as a credit card supplier using Communications Network 303 before 
purchasing is allowed. This process is well known to those in the art. 

10 

A buyer wishing, and permitted, to make a purchase can trigger the Transaction Management Module 423. 
This will offer a page such as that shown in Fig 1. that establishes the following, (a) What he wishes to 
purchase (for example: the time of a temporary secretary) This information is sent to the Market Rules 
Database 434 which provides the parameters which must be defined to enable a search of the Seller Database 
15 , 431. (b) The quantity he wishes to purchase (for example by defining a period of daily hours which the 
system can multiply by the number of days input at the next step), (c) The times he wishes to purchase (for 
example: by defining a start and end date for a booking), (d) The geography in which he wishes the purchase 
to be realized (for example: place of work is postal code Y). 

20 Transaction Management Module 423 will ensure all required information is in place before beginning a 
search. Once the required inputs have been completed the Transaction Management Module creates a record 
on the Transaction Database 433. A unique identifier code for this transaction is established at the time of 
storage. The Transaction Management Module 423 then initiates a search of the Seller Database 431 based 
on the buyer inputs. The search is performed by Assembly of Options Module 424. It excludes those sellers 
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who are among any of the following, (a) Not selling the services/goods the buyer wishes to purchase, (b) Not 
willing to sell in the area defined by the buyer, (c) Not willing to sell the number of units (for example hours) 
demanded by the buyer, (d) Not willing to sell with the period of notice for this transaction, (e) Not available 
at the dates and times the buyer requires, (f) Not contactable in the time required before the purchase. 

Thus the Assembly of Options Module 424 fa-able to return a list of any sellers on the database who meet the 
following conditions, (a) Selling the services or goods required by the buyer, (b) Willing to sell in the 
geography required, (c) Willing to sell with the period of notice specific to this job. (d) Available for the 
times and dates required, (e) Contactable in time for this booking. 

This list is sent to Price Construction Module 425. In it simplest embodiment, this module looks up the unit 
price for each seller on the list, such data being held in Seller Database 43 1 and multiplies it by the number of 
Unitsf0r this " sffle: '^natively if may uielhe ^s'ellfng parameterloTthe present requirement as outlined in the 
screen shown in Fig 1, coupled with a list of pricing preferences from each user,, to construct a specific price 
for this one transaction for each seller. It may also add a mark-up input by the system operator through 
Service Provider Terminal 308. This provides revenue for the market operator and is retained during any 
subsequent transfer of payment between buyer and seller. Alternatively the market operator might invoice 
either party for its transaction fee, or subscription fee, at a future date. 

This list of options and their prices is stored in the Transaction Database 433 against the unique identifier for 
this query. If no sellers are returned the Transaction Management Module 423 creates a message for the 
buyer suggesting a change of requirements. 

The list of sellers and prices thus stored are now sent by the Communications Processor 304 and the 
Communications Interface 304 to the Buyer Terminal 302. Before doing so Assembly of Options Module 
424 may apply rules such as "display in price order from left to right putting identically priced sellers in 
alphabetical order" or "only display a maximum of 20 sellers on one screen". Such rules would be input from 
Service Provider Terminal 308. 

One embodiment of such a page is represented in Fig. 2. If the buyer selects "purchase" on any option or 
options presented to him, that information is stored in the Transaction Database 433. A page of information 
for the seller has to be completed by the buyer and payment is arranged according to instructions in the 
Market Rules Database 434 by Payment Transfer Module 427. This module will access proprietary software 
well known to those in the art such as credit card approval, transfer of digital value between users on the 
system or invoice generation and return a "payment OK" flag to be recorded on Transaction Database 433. 

Once payment arrangements have been confirmed the Post Sale Management Module 426 is triggered. This 
performs the following tasks, (a) Confirms the seller is still available. If they have removed their availability 
or been bought by another conflicting buyer since the search showed them to be available the buyer is 
advised with a message, (b) Removes the appropriate availability from the seller's record in Seller Database 
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431. (c) Creates a message for the chosen seller revealing the buyer's identity stored in Buyer Database 432 
and adding details of his purchase from Transaction Database 432. In a temporary work transaction these 
would include: place of work, hours of work, days to be worked and information input by the buyer to be 
passed to the seller, (d) Looks up contact details on the Seller Database 431 and directs the message to email 
5 or mobile phone for instance via the Communications Processor 304. (e) Monitors that the seller confirms 
they will undertake the assignment before the start of work time. If they do not a message is generated for the 
buyer advising that the seller has not confirmed and the buyer may wish to re-book, (f) Triggers release of 
payment from escrow funds at a specified point based on rules in the Market Rules Database 434 (for 
example 48 hours after completion of the transaction). In a temporary work market this would be likely to be 
10 based on completed timesheets each of which triggers an invoice. Online timesheets may be based on 
technology such as Web Timesheet from Adeo Software or the Time product from Artologik Software 
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It will be appreciated that modules listed above could be combined in practice. Their listing is purely 
illustrative of the functions to be performed and is not intended to define the system's structure. 



Benefits of the system 

This is a "spot market" online. Existing systems for buyer/seller matching tend not to allow immediate 
purchasing from an infinite number of sellers who may have entered the market only minutes earlier. Online 
bulletin boards offer listings of sellers who may be available for a general need. Internet auctions require time 
20 consuming bidding. Using bid/ask systems the buyer must define parameters of the potential purchase which 
has to be matched by a precise offering defined by the seller. 

"GEMs" type markets such as that just described provide a list of named sellers any one of whom can be 
booked immediately for a buyer's specific requirements. Unlike online catalogues these markets are able to 
25 construct a specific offering for a buyer's needs based on much more general inputs by a plurality of potential 
sellers. 

There are potential enhancements to a system as described above that are already in the public domain: 

30 Tailored price construction embodiment. 

In this embodiment Seller Parameters Record 43 la additionally stores pricing data that can be updated by the 
seller using a screen generated by User Maintenance Module 428. Each seller is able to have information 
stored that enables their individual price for each assignment for which they are applicable to be constructed 
by Price Construction Module 425. In this embodiment each seller gives the system a basic rate for each unit 

35 of sale that is stored in Seller Database 43 1 (for example "my price per hour is $10"). They can then dictate 
that percentage mark ups be added to that sum based on how the buyer's requirements relate to the individual 
seller's preferences around parameters relating to that market. 
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To achieve this, the seller is asked questions by Seller Registration Module 221 relating to the market in 
which they are selling. In a secretarial market these might include: 



I) 
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"What percentage mark up do you want added to your basio price if a job requires the distance you travel 
from your home postalcode is: (a) More than 1 mile but less than 2 miles? (b) Between 2 miles and 5 miles? 
(c) Between 5 miles and 10 miles (d) Between 10 miles and 20 miles? (e) Between 20 miles and 40 miles? (f) 



Over 40 miles?' 
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It will be appreciated by those skilled in the art that geographical calculations such as this can be computed 
by comparing seller base postalcode and buyer required postalcode in a variety of ways at the time of search. 
Typically they include route planning software such as IntelliRoute by Rand McNally or Ziplnfo from 
Scribble software. The seller can select an "X" on any option to signify they should be excluded from the 
search for jobs with that characteristic. 



Similar questions are asked of each seller at the time of registration by Seller Registration Module 421 to 
produce a set of rules specific to each seller which are stored in the Seller Parameter Record 431a. They 
might cover the following, (a) Geography: (for example: if the job is more than 1 mile from my home 
postalcode I charge an extra 10%. If a job is more than 5 miles from my home postalcode I charge an extra 
20%). (b) Size of purchase: (for example: if the job is less than 2 hours I charge an extra 10%, if the job is 
. less than 4 hours I charge an extra 5%.). (c) Period of notice to purchase: (for example: "if I have less than 24 
hours notice of the job starting I will charge an extra 20%, if I have less than 12 hours notice I will charge an 
20 additional 40%.). 

It will be clear that the system can thus construct a price at which a relevant seller will complete the buyer's 
specified requirements. For example: 

25 Basic rate is $1 0 per hour 

Job entails traveling 1.5 miles so add 10% of basic rate = $] 

Job is 3.5 hours long so add 5% of basic rate = $0.50 

Job entails 75 hours notice of start so percentage mark up input = $0.00 



Thus the seller's hourly price for this buyer's requirements are $10 + $1 + $0.50 + $0.00 = $1 1.50. 

It will be appreciated that this instant pricing of a buyer's requirements allows individual sellers to offer their 
goods or services knowing that they will be compensated for the specific aspects of any sale with most matter 
to the individual seller. 

Grading of sellers embodiment. 

In this embodiment User Maintenance Module 428 promotes sellers up a ladder of grades as they complete 
specified numbers of trades. Buyers can view relevant sellers produced by the search listed by their grades in 
the market. Grading data is stored on the Seller Database 43 1. Users may move automatically through grades 
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as the User Maintenance Module 427 periodicaily sweeps the seller database checking number of units sold 
in each market. 

Market overview embodiment. 
5 By sweeping details of transactions held in the Transaction Database 433 including the sale price, times, 
dates and geographical point required by buyer a market overview module would be able to plot trends in the 
market for users. Anyone defining a market sector, a geographical area and a time period can then see data 
which might reflect the following, (a) Number of units sold in that geographical area/timeframe. (b) Average 
price of units in that geographical area/timeframe. (c) Number of sellers listing their availability in that 
10 geographical area/timeframe. (d) Range of periods of notice of purchases in that geographical 
area/timeframe. 

It will be appreciated that this enables potential sellers to make decisions about market entry. Established 
sellers can identify patterns of demand. Buyers can select the times or geographies when they can purchase 
1 5 more cheaply. 

WIPO patent application WO 02/091100 discloses in detail a GEMs system that allows the transactions of 
high grade sellers to be economically underwritten by the system operator. Underwritten transactions might 
20 have a monetary amount attached that specifies the maximum that can be spent on a replacement purchase. 
This document is incorporated herein by way of reference material. 

UK patent application 0326895.0 discloses in detail a means of encouraging agencies and other market 
middlemen to register sellers in an online marketplace. This document is incorporated herein by way of 
25 reference material. 

The present inventor has disclosed basic details of "GEMs" markets in two books: "Guaranteed Electronic 
Markets; backbone of a 21 st century economy?" (Pub: Demos, 1997) and "Net Benefit: Guaranteed 
Electronic Markets the ultimate potential of online trade" (Pub: Macmillan 1999). 

30 

Background to the present invention 

The present invention concerns the offering of availability by sellers in a marketplace. Any market system 
which is to offer buyers the prospect of an immediate purchase from any number of potential sellers, rather 
than simply offering a list of possible sellers who require dialogue to establish whether they will sell what is 

35 required, must maintain some record of what is available for sale, when it can be sold and at what price. In a 
single seller environment this is typically achieved through inventory management software, for example 
within an online bookstore. More recently yield management disciplines applied for example to airline seats 
has led to "dynamic pricing" where a seat on a flight is priced according to the proximity of departure or the 
popularity of the flight. Although flexible, the item being sold is uniformly available to the entire market at 

40 the same price. 
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The present invention provides for a sophisticated system that allows an infinite number of sellers to control 
their individual availability and pricing with extraordinary precision. The technology disclosed can 
_ in L m ! diat . e | y _ a _ SSeSS Wl !! ther an _ y °™ of ^thousands of sellers is available for a particular transaction 
based on: any combination of parameters of that transaction, events in the wider market and their own" needs 
in an market. The market in which they are selling may be of the "GEMs" type outlined above or any other 
forum in which sellers list their willingness to sell at specified times in advance of those times. Once a seller 
is deemed to be available for a particular transaction the price at which they personally will fulfil it can also 
be instantly calculated. 

Typically this functionality will be most useful in markets with large numbers of potential sellers, likely to be 
individuals or small firms, with non standardised goods or services being offered (that is, not uniform 
barcoded items such as books) and a small size of average transaction. The technology may be deployed in a 
market of multiple buyers, for example an exchange for sellers of household services, or a market in which 
there is only one buyer, for example a large employer who chooses to allow staff to sell themselves 
competitively into periods of work with as much flexibility as they wish. 

Prior Art 

It is known that "availability diaries" are used by those who sell the time of temporary workers. For example 
software designed to automate temporary work agencies often features an online weekly record where a 
temporary is invited to select "available" or "not available" for the morning, afternoon and evening of a each 
day in the forthcoming week. Alternatively this data can be input by agency staff who have phoned a 
temporary worker in search of the information. Pioneers of this type of software include Bond Adapt 
(www.bondadap t.co.nk) provider of recruitment industry automation and Tempz.com an online temporary 
work agency. These work diaries may be characterised as binary: for each given period a worker is either 
available or not. There are no degrees of availability'. Similar availability diaries are used in services such as 
the booking of hotels and guesthouses where rooms are either available for a given night or not. Likewise 
plant hire rental and comparable markets are often based around availability diaries that are broadly binary. 

Also known is employee or resource scheduling systems which are driven by "top down" scheduling 
Typically these products (a) profile the skills and qualifications of a firm's individual workers possibly with 
weighting for their suitability for a variety of tasks (b) record a profile of the requirements for particular 
positions within the firm (c) allow input of numbers of staff required for particular functions at a particular 
time (d) store the rates of pay for each individual worker or each individual post (e) output the most cost- 
effective shift pattern for any given week based on specific requirements and factors such as staff holidays 
requested days off and staff hours worked oyer a defined period (f) provide full management reporting and 
payroll information on the shift pattern produced. 

US6,192,346 discloses a form of employee scheduling that allows individual workers to bid for time off with 
priority based on their seniority. Covering shorter periods of time, US6.587.851 explains technology for 
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scheduling mobile technicians, such as field service engineers, so that they are matched with jobs with the 
minimum of travel. US6,683,947 outlines a means of scheduling call center workers based on the center's 
requirements while US6,594 5 470 demonstrates technology that allows management of call centers, including 
staff monitoring, to be carried out from a remote location. In a related field, US5,1 17,353 covers a system for 
5 running a temporary work agency that features a record of the individual's availability for each day of work. 

The art includes Enterprise Human Resource Planning systems such as those offered by Rostima 
f www.rostima.com ) , Schedulesource r www.schedulesource.com) , Shiftiogic fwww.ad-QDt.com) and 
Amcomsoft r www.amcomsofl.com) . However, these systems typically (a) assume the individual is paid a 
10 rate set by the buyer with perhaps pre-determined incremental increases, for example for out of hours 
working, (b) reflect the employer's priorities not those of the seller or employee by for example offering 
ample opportunities for the employer to reduce their labor costs but little sophistication for the worker who 
wishes to maximise their income within the system (c) take little account of an individual's needs beyond 
allowing time off requests and holiday inputs. 

15 

Work availability diaries that offer more sophisticated choices to employees have emerged in industries 
where there are multiple factors affecting the times of work. For example, airline long-haul cabin crew 
rosters can factor in (a) an individual's willingness to spend stop-over time at a particular destination (b) their 
willingness to be away for the duration of a' particular trip. This is achieved in systems such as Interbid by 
20 Carmen of Sweden, ( http://www.carmen.se/ ) as used by British Airways and other carriers, by awarding staff 
a notional number of points for each scheduling period. The number of points may increase with seniority 
and allow workers to bid for flights they most want to work by "spending" their points. But the system 
typically requires staff to (a) -work a minimum number of hours (b) accept at least some shifts they would 
rather not perform (c) be inflexible in the way they commit in advance to future schedules. 

25 

Software is widely used to manage individuals' diaries. US6,144,942 outlines a means for notifying users of 
events they have previously indicated to be of importance by a plurality of devices. For corporate personnel, 
US6,064,976 provides for a system that automatically updates a user's availability for meetings and other 
events with little user input. Similarly, US6,01 6,478 shows how technology can be used to facilitate the 
30 scheduling of group meetings with the optimum time for all participants discovered. US6,380,959 discloses a 
method for creating interactive online calendars such that video or animation can be used to present 
information. 

Other forms of scheduling of individual sellers that are well advanced include the scheduling of taxis within a 
35 given area. Such systems typically require (a) a terminal in each car (b) a central controller which receives 
orders either direct from customers or from a human controller. Typical processes include (a) receiving a 
request for a cab (b) deciding on the most eligible taxi in the fleet based on location, input either manually by 
the driver or through a GPS transmitter, or a combination of location and recent lack of customers (c) 
informing a driver of his . next transaction (d) receiving confirmation (e) updating cab location records. A 
40 market leader in this technology is Mobisoft of Finland (www.mobisoft.fi ). 
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The ability to construct prices based on buyer demand is well known. US5,752,238 discloses a consumer 
driven electronic information pricing engine. US5,822,736 and US5,987,425 cover a variable margin pricing 
system that allows the pricing sensitivity of a retailer's goods to be established with pricing then constructed 
dynamically. Similarly, US6,076,071 disclosed a means of changing the" prices in a virtual store inline with 
demand and advertising for each product. US6,684,400 describes a system that calculates the optimum price 
for digital information. US6,336,097 discloses a means of constructing large numbers of travel fares in real 
time based on matrices covering geographic areas that can be combined in multiple ways to arrive at an 
optimal price. 

Thus individual sellers in the art tend to be either scheduled according to the priorities of a big buyer, with far 
less flexibility around the seller's needs, or scheduled according to binary availability on the assumption that 
all who are available at any given time are equally available. There is little opportunity for sellers to compete 
with each other through price or changing the terms under which they will sell: Although Enterprise software 
is predicated on considerable awareness of the complexities of a modern corporation there is little account 
taken of the complexity of individual seller's willingness to sell. Neither employee scheduling software or 
availability diaries in the known art can accommodate availability accompanied by conditions such as: "I will 
only work this evening if I can find a childminder once I know I have a booking", "I'm not keen to work next 
weekend but I will if the weather is bad because then I am likely to be in more demand", "I can only work on 
Thursday if my sister is working the same shift to provide the transport and my husband is not working so he 
■ can look after the baby". 

There are other drawbacks within the art. Sellers who undertake to complete transactions for which they are 
booked at times for which they have displayed availability might be purchased for a small percentage of that 
availability which then renders the rest effectively unsaleable for the much larger period they had had hoped 
to be working. Sellers have little means of promoting themselves or trying new patterns of selling. For 
example, a seller may wish to experiment with different pricing or an upgraded offering but progressively 
retreat to an offering more in line with typical market demand as the block of availability in question gets 
nearer if the signs are their experiment is unsuccessful. Sellers may wish to respond to events in related 
markets that they believe will increase or diminish demand in their own sector. Achieving any of this with a 
binary availability diary is extremely time consuming, relying on manual changing of inputs, if it is possible 
at all. 

Because of these drawbacks there is currently a reluctance by sellers to commit to the inputs in an availability 
diary. Outside of employee scheduling processes or other systems where the seller (worker) has a pre- 
determined contractual obligation to the buyer (employer), sellers tend to prefer that their availability entries 
be used as a guideline while assignments are confirmed, and rates finalised, in a dialogue with a buyer or an 
intermediary. This is time consuming for both sides and inhibits the immediacy of purchase that allows 
buyers and sellers to make very precise decisions about market entry at the last minute. 
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There therefore exists a need for functionality that will allow any seller to have periods of "Conditional 
Availability", that is offering units of sale which are only available dependant on an infinite array of 
parameters which might include: 

• Characteristics of a transaction for which they might be suitable 
5 • Market activity 

• The seller's own performance in the market 

• The seller's personal circumstances 

• Events outside the market, such as the weather or local events 

10 Such functionality would be most useful in an environment where (a) sellers have access to detailed Market 
Overview information allowing them to see patterns of demand, supply and pricing in their markets in their 
area; they may wish to make market entry at a particular time dependant on this data (b) sellers operate in a 
market which penalises them, for instance . with a downgrading, if they say they are available but they 
subsequently fail to fulfil purchases of their time or goods made on that basis. In such an environment it is 

15 particularly important that sellers are able to specify "I am only available if...." at any time they choose. 

Summary of the invention 

According to the invention, there is provided a transaction management system for managing the purchase of 
a product or service by a buyer from a seller, the system comprising: 
20 a data store for storing seller data comprising, for each of a plurality of sellers, a seller identifier; 

a program store storing processor implementable instructions; and 

a processor coupled to the data store and to the program store for implementing the stored 
instructions, wherein the stored instructions comprise instructions for controlling the processor to implement 
a seller interface to receive seller offer data from a seller, the seller offer data including an availability record 
25 for a product or service offered for sale, the availability record defining a plurality of periods of conditional 
availability, each period of conditional availability having an associated set of conditions under which the 
product or service is or is not available. 

By allowing for a seller to indicate periods of conditional availability in an availability record, the invention 
30 provides a flexible transaction management system in which sellers are more likely to indicate some form of 
availability. 

Preferably, the data store is further for storing the seller offer data received from a plurality of sellers by the 
seller interface. Availability of the product or service during the periods of conditional availability is 
35 preferably dependent on data internal or external to the system. 



Preferably, the seller interface is further implemented to receive a plurality of sets of conditions from a seller, 
each set of conditions comprising an availability rule. In this case, the data store is preferably also for storing 
the availability rules received from a seller by the seller interface. The data store may also store a plurality of v 
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predefined availability rules. The seller interface may then be implemented to facilitate construction of the 
ava,lability record for a product or service by receiving periods of conditional availability associated with 
availability rules from the seller. Such an implementation provides a simple yet flexible mechanism for 
building the availability record. 



The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a buyer purchasing at least one linked product or service. In this 
case, the at least one linked product or service may be offered for sale by at least one different seller, and the 
seller interface is further implemented to notify the at least one different seller that the products or services 
10 have been linked. 
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The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on at least one linked product or service being available to the seller. 

The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a purchase comprising less than a defined amount of the period of 
conditional availability. Alternatively, the availability record for a product or service may define that 
availability in at least one period of conditional availability is dependent on a purchase comprising more than 
a defined amount of the period of conditional availability. 



The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a linked product or service not being purchased for the period of 
conditional availability. The availability record for a product or service may define that availability in at 
_ least one period of conditional availability is dependent on the seller's revenue or profit in a preceding 
> timeframe. 

The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a travel distance associated with the buyer from a preceding buyer 
location. Alternatively, the availability record for a product or service may define that availability in at least 
one period of conditional availability is dependent on a travel distance associated with the buyer from a 
current location of the seller. In this case, the system is preferably arranged to determine the current location 
of the seller based on signals received from a global positioning system device or a cellular telephone device. 

The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a defined reduction in the availability of products or services in a 
defined market. The availability record for a product or service may define that availability in at least one 
penod of conditional availability is dependent on a defined rise in the price of products or services in a 
defined market. 
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The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on the seller having sold a defined number or value of linked goods or 
services by a defined time before the period of conditional availability begins. The availability record for a 
product or service may define that availability in at least one period of conditional availability is dependent 
on a linked product or service being unsold at a defined time before the period of conditional availability 
begins, the linked product or service being a larger quantity of the product or service offered for sale. 

The availability record for a product or service may define that availability in at least one period of 
conditional availability is dependent on a defined increase or decrease in the price of the product or service. 

The availability record for a product or service may further define a plurality of periods of unconditional 
availability or unconditional unavailability. 

The seller interface may be implemented across the Internet The seller interface may alternatively or 
additionally be implemented across a cellular telephone network. In this case, the availability record may be 
based on SMS text messages received by the seller interface across the cellular telephone network. 

The stored instructions preferably further comprise instructions for controlling the processor to implement a 
buyer interface to: 

receive a purchase enquiry from a buyer, the purchase enquiry including a required period of 
availability for a product or service; 

output seller offer data for a plurality of sellers able to provide the product or service for the 
required period of availability; and 

receive a purchase request from the buyer accepting an offer. 

Preferably, the buyer interface is implemented to only output seller offer data for products or services that are 
conditionally available if the associated set of conditions are met. The system may be arranged to determine 
whether the set of conditions are met at a predetermined time before the associated period of conditional 
availability. Alternatively, the system may be arranged to determine whether the set of conditions are met 
when a purchase enquiry for the products or services is received form a buyer. 

The buyer interface is preferably implemented over the Internet. 

The seller interface may be further implemented to indicate the current availability of the seller's products or 
services during periods of conditional availability. The seller interface may also be further implemented to 
indicate the potential availability of the seller's products or service during periods of hypothetical conditional 
availability. In either of these cases, the seller interface may be further implemented to indicate the 
availability of other sellers' products or services. As well as availability information, the seller interface may 
also be implemented to indicate price information. 
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The system is for managing the purchase of products or services by one buyer from a plurality of sellers 
Alternatively, the system may be used by several buyers and may operate across several underlying markets. 

AC !°!: ding ^ 0 _ a _ S !! 0n . d _ aSpe _ Ct ° f the invention > there is P^ded a method for managing the purchase of a 
product or service by a buyer from a sel ier, the method' comprising: "" " " * ' 

storing in a data store storing seller data comprising, for each of a plurality of sellers, a seller 
identifier; and 

implementing a seller interface to receive seller offer data from a seller, the seller offer data 
including an availability record for a product or service offered for sale, the availability record defining a 
plurality of periods of conditional availability, each period of conditional availability having an associated set 
of conditions under which the product or service is or is not available. 

The method aspect may have corresponding features of the system aspect. 

The invention also provides a computer software product arranged to cause a computer to execute the above 
method and a computer readable recording medium having encoded thereon at least one program for 
performing the above method. 

As shown in Fig 5a, Availability Server 500 is connected to, or forms an integral part of, at least one 
marketplace in which a plurality of sellers transact with one or more buyers. The sellers list their willingness 
to sell specified goods or services at a particular time, at that time or in advance of that time. Said 
marketplace may already have a facility to allow sellers to list times when they are willing to sell such as 
Seller Availability Record 431b described earlier. This is modified to either (a) allow itself to be replaced by 
the present invention for sellers who wish to interact with Availability Server 500 (b) take in seller's standard 
availability and times of non availability but additionally flag periods of time when a seller is conditionally 
available and their listing for any given transaction must be subject to assessment by Availability Server 500. 

The present server allows any seller to allocate a conditional willingness to sell to a block of future time. A 
wide range of data can be accessed and analysed to see if an individual seller's conditions for availability for 
a particular transaction at a particular time have been met. If they have not, the seller is deemed not available 
and may not be displayed as an option for the buyer. 



A user of the present invention is able to create a plurality of rules that can then be applied to any block of 
future time they wish. Rules specify "At this time the seller is only available if....". Examples of rules 
35 expressed colloquially might be: (a) prices in my market are well above average" (b) «.... my husband 

and I together have earned less than $400 in the last week in the marketplace" (c) « the buyer is a 

registered corporation rather than a small trader". Individual rules can be merged if there is no contradictions 
between them, for example a user could apply all three conditions above to a block of availability, thus their 
rule covering those hours becomes: "At this time I am only willing to sell if prices are high, our household 
budget is down and it's a corporation that want me to work". 
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Each user runs an availability diary in which they list future periods of availability to sell with , if they wish, 
a rule attached to each period. This is stored within Enhanced Availability Store 560. A skilled user may 
choose to create their own rules by defining (a) one or more sources of data anywhere within Availability 
5 Server 500 or an underlying marketplace (b) the data to be extracted from said source (c) any calculations to 
be performed on said data (d) a comparison figure above or below which the user is to be deemed available. 
Additionally there needs to be verification to protect a user from basing a rule on sensitive data, such as 
another seller's sales record, without permission. 

10 Rather than creating rules from scratch, it is easier for users to work with pre-formed rules to which they 
need only add their personal thresholds for availability; Thus Availability Rules Store 550 contains a table of 
pre-formed rules each of which is made up of (a) wording and selections of thresholds which are offered to 
users who wish to add this rule to their portfolio (b) the process steps, as outlined for user created rules 
above, which must be followed to establish if a seller is available at any given time when this rule is in force 

1 5 (c) any actions required to protect other users or otherwise ensure the integrity of the market before this rule 
can be applied by a user. 

Rules fall into three broad categories: 

• Search requirements: availability is dependant on a search carried out when a purchase request, for 
20 which the seller may be available, is received at a time when the seller is displaying conditional 

availability. Availability Search Module 520 will then ascertain whether the requirements for 
availability are currently met. For example: "Our fork lift truck is only available for hire at this time 
if the loadspace in trucks market in the underlying system of marketplaces has risen by more than 
10%". A search can lead to an action or .the construction of a package for the buyer. For example "I 
25 am only available at this time if one of my approved assistants is also available and booked as part 

of the same transaction." 

• During-availability sweeps: Seller Monitoring Module 540 checks repeatedly throughout the given 
period of availability that the conditions are met. For example: "I am only available to work if there 
is a signal from my mobile phone at the time." 

30 • Advanced sweeps: Sweeps Module '535 checks the progress of a particular transaction, or the state 

of the market, at a specified time, for example "My 500 bales of hay will be available for sale on 
Saturday, if they have not been bought by Friday then I want them automatically broken into smaller 
lots". 

35 As well as applying a rule to a period of availability a user may specify additional conditions for their 
availability. These include (a) a change in pricing, for example "if I am listed as an option under this rule add 
another 10% to my price" (b) a change in the selling parameters, for example "at times when I am available 
under this rule I am only willing to work within 5 miles of my base postalcode and only on jobs with at least 
48 hours notice". 
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Additionally, a user can specify actions to be carried out by Availability Server 500 at times when, or after 
they have made a sale under the terms of conditional availability. They might for example decide "if I am 
going to work on Wednesday evening, I want to then cancel my next 4 hours of unsold availability" They 
5 can also change the way they" are (a) contacted" by the system to'advise them of a sale," perhaps demanding 
add lt ionaI means of contacts during periods when they are only going to have their goods or services sold in 
unlikely circumstances (b) accepting assignments (c) priced for future assignments. 

Sellers can view reports on their availability patterns that may include "what if..." scenarios reporting sales 
10 *ey may have made had they applied different availability rules. 

Availability Server 500 works for sellers of either goods or services. A seller of services, or hirer of goods 
inputs availability into a grid of hours, or other units of time, for each week. A seller of goods must also 
interact with inventory management software that will require they specify the quantity' they have to sell 
15 Thus, their availability has two components attached to each potential sale. "I have 50 bundles of flowers for 
sale and will act on orders between 10.00 and 12.00 on Saturday and between 16.00 and 18.00 on Sunday " 
The management of inventory is well known in the art and is not described in detail in this document. Where 
a seller is offering goods the present invention will check with associated inventory software that the seller 
has not exhausted the goods they have to sell and, only if there are still stocks to meet a buyer's needs, list the 
20 seller as an option for a particular buyer. 

The descriptions of components and processes above and in the rest of this document are illustrative only It 
will be clear to those skilled in the art that the architecture required could be achieved in an infinite range of 
ways. 

The facility to apply multiple "types of availability" to future periods may be used only at its simplest level 
by a user. An individual worker for example may simply decide "I will only be available to work in the 
evening if an assignment is within 2 miles of home and I get an extra 20% compared to the prices I would 
expect during the day". However, assuming they would not be willing to make an unqualified commitment to 
selling at this time, by using the present invention they have (a) brought increased availability into the market 
(b) ensured pricing within the market more accurately reflects the seller's willingness to sell under any given 
conditions (c) by increasing the range of offerings for a buyer's needs, made the market both more 
competitive and better able to respond to short notice purchasing. 

Responsiveness to short notice purchasing benefits all users in a marketplace. Buyers are able to make 
precise purchases at the last moment at a competitive rate rather than booking in advance, when their needs 
are still unfocused, to be sure of meeting their requirements. In a market in which many buyers routinely 
make last minute purchases sellers are able to routinely make their own market entry decisions at a late stage 
if they wish. 
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As users become comfortable with the idea of different types of availability applied to any block of time 
when they might potentially be available to sell they are likely to use the facility with increasing 
sophistication. A seller who has never previously considered night work might begin to input availability that 
specified "I am available to work night shifts for a trial week if (a) I get at least 5 days notice (b) mynormal 
5~~ rate is" doubled "(c) the weather forecast for that period is good (d) I have not found work in the daytime that 
week. This ease of experimentation allows 'the market to expand, perhaps establishing night piecework 
options in sectors in which it had never before been a realistic option for buyers. Without this sort of facility 
finding a temporary worker to do a one off night shift would have been too time consuming, entailing a 
process of phoning round seeking to cajole a qualified worker into complying with the buyer's needs with no 
10 idea of the price at which they would fulfil the need. 

Assuming the underlying marketplace allows immediate purchasing, a buyer can simply input their 
requirements for a night worker and see if anyone has chosen to be available, whatever their terms. If only a 
handful of sellers chose to list in this way prices are likely to remain high. If the underlying market offers 
15 users an overview of evolving demand, supply and pricing patterns in their area then night work hiring could 
attract more sellers, each with their own conditions for availability and pricing will increasingly reflect the 
willingness of sellers to provide for the changing needs of buyers. 

A truly sophisticated user of the present invention might never list a period of non-availability. Instead they 
20 have increasingly strict controls, with increased prices, applied to periods when they would rather not sell and 
actions to be applied after a transaction to ensure they get the breaks they need. They would thus be 
interacting with the market on entirely their own terms yet putting themselves in the most competitive 
position to take advantage of trends in demand and supply. 

25 Brief description of the drawings 

Fig 1 shows a completed buyer input screen within a known online marketplace defined by an ability to take 
in a buyer's requirements and immediately construct options specific to his needs based on broader inputs 
from any number of sellers; 

30 Fig 2 illustrates an exemplary screen returned by such a marketplace in response to the buyer input in Fig 1 ; 

Fig 3 is a schematic illustration of the communications links required for this known marketplace and which 
can form the basis of the system of the invention; 

35 Fig 4. represents the system architecture within the Application Processor' 306 and Datastore .307 for the 
system of Figure 3; 

Fig 5a shows a possible relationship between Availability Server 500 and one underlying marketplace; 
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Fig 5b illustrates one embodiment of the architecture required within Availability Server 500; 
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Fig 6 contains a potential table of wording and selections for pre-formed availability rules such as might be 
stored within Availability Rules Store 550; 

5 Fig 7 accompanies Fig 6 and shows a table of processing actions accompanying each of the sample" pre- 
formed availability rules; this information is also stored within Availability Rules Store 550; 
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Fig 8. illustrates a screen, generated by Availability Management Module 515, that allows a user to create 
their own version of pre-formed rules; 

Fig 9 is indicative of the table of an individual seller's rules stored within Seller Database Extensions 555; 

Fig 10 shows one embodiment of a screen through which a user may specify periods when they will be 
available to sell and apply any one of their rules to a period of availability; - * ......... 

Fig 11 is indicative of the grid of availability for one user for a week that is stored within Enhanced 
Availability Store 560; 

Fig 12 flowcharts the process of performing an availability search as potentially carried out by Availability 
Search Module 520; 

Fig 13 illustrates the table of availability blocks that is assembled as part of the above process by Availability 
Search Module 520; and 

Fig 14 shows a potential screen for reporting to a seller on the way they have been displayed to buyers as a 
result of their availability instructions over a given timeframe. 

Detailed description 

Description of the architecture 

As illustrated in Fig 5b, Availability Server 500 contains Availability Application Processor 505 which 
contains the following modules: 

515 Availability Management Module: allows sellers to select the types of availability they wish to offer and 
input periods of controlled availability into the server. 

520 Availability Search Module: searches any sellers for a potential sale who have "conditional availability" 
to establish whether the parameters they have'set qualify them for a particular purchase request. This module 
is also able to check with inventory software, as known in the art, on the stocks of goods a seller has 
remaining. 
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525 Post Purchase Module: implements any change of instructions selected by a seller who is purchased 
under the terms of "conditional availability", this might include how the seller is to be contacted or any 
changes to their future willingness to sell as a result of obtaining a sale under their terms of conditional 
availability. 

530 Availability Analysis Module: allows sellers to see the consequences of their Conditional Availability in 
terms of the buyers' requirements that they matched and those they missed, it also allows new sellers to 
model various availability options based on historic market data. It is able to trigger seller search and price 
construction in the underlying marketplace to run data from past transactions with the addition of 
hypothetical seller data for a seller who wishes to model the likely effect of changes in their availability. 

535 Sweeps Module: carries out advance sweeps of data within the system and over-rides entries in the seller 
database on the instructions of a seller who wishes to re-sell their commitments, for example because 
required numbers of purchasers have not been met. 

540 Seller Monitoring Module: carries out during-availabiiity sweeps, for instance checking that a given user 
is contactable or active on their specified computing device or their location as reported by a GPS style 
device. 

Availability Datastore 510 contains the following records: 

550 Availability Rules Store stores templates of pre-formed rules which users can personalise for setting up 
their own conditions of availability. Information is input from Service Provider Terminal 308. 

555 Seller Database Extensions contains an extension to Seller Database 431 for any user who wishes to 
offer conditional availability, it stores the terms of each individual trader's various conditions of availability. 

560 Enhanced Availability Store contains an extension to Seller Availability Record 431b, or replacement of 
that record, for each seller who wishes to interact with the present invention, it stores the days / hours when 
each user is available subject to their conditions being met plus for each unit of time (half hour for example) 
a base postalcode for the area where they are to be available at any given time (by default, the seller's base 
postalcode), the times when availability was input and a record of the hours for which they are booked to 
work. 

565 Historical Datastore stores the details of every seller offered to a buyer, how their price was constructed, 
the buyer's requirements that triggered the search and the price of each option every time the screen 
represented in Fig 2 is generated, this is used for seller availability analysis. This module also archives 
availability records from Enhanced Availability Store 560 once the time of availability has passed. 
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570 External Variables Datastore extracts or accepts data from external sources that may be used by buyers 
to determine whether they are willing to sell, said data may include for. example weather forecasts or 
timetables of local events. The range of transfer protocols available for such information intake are well 
known to those in the art and include systems .such as RSS (Really Simple Syndication). 

575 Operator Inputs Datastore holds market operator instructions covering, by way of example, the frequency 
with which sweeps to ascertain a seller's locality are to be carried out. 

Overview of availability rules. 
10 Whether a seller is available at any particular time is determined by their availability diary stored within 
Enhanced Availability Store 560. Any seller who wishes to use the facilities of the present invention is able 
to establish rules governing their Conditional Availability which enables Availability Management Module 
515 to set up a record in Seller Database Extensions 555. 

1 5 A seller may have an infinite number of rules governing their Conditional Availability stored on their record 
within Seller Database Extensions, 555. Each rule can then be applied to any block of future time of that 
user's choosing. For example; "next Thursday between 1 8.00 and 22.00 I am available to work subject to my 
rule 17". An individual's rules might include options specifying they will only work if, for example (a) they 
have missed their personal income targets (b) they can purchase something in an adjoining market they 
20 themselves need to complete a potential transaction, a minicab journey to a place of work for instance (c) the 
number of sellers in their chosen market sectors is below average at the time of conditional availability. By 
default, Availability Server 500 will assume a seller who is available under the terms of their conditional 
availability is to have their standard parameters for sale and price construction as stored in Seller Database 
431 applied. 

25 

The application of each rule is defined by the seller's inputs. Thus, in the three examples above, Seller 
Database Extensions 555 can not assess whether the seller is available at a particular time without (a) a 
record of their personal target figure and a timeframe which can be compared with their earnings, as stored in 
Seller Database 431, for that timeframe (b) a specification of the purchase on which their availability is 
30 conditional (c) the timeframe for calculating an average and the percentage below that at which the seller is 
willing to enter the market. 

Thus, any rule for conditional availability is stored in terms of: (a) the relevant data sources within the system 
for locating the data on which an assessment of whether the seller is available will be made (b) the precise 
35 data to be extracted from each source (c) any calculations or comparisons between data to be performed (d) 
the threshold figure above or below which the seller is to be deemed available. 



40 



Sophisticated users may wish to set up their own unique availability rules by specifying all details required to 
construct their own version of the process outlined above. This can be done by means of a screen generated 
by Availability Management Module 515 offering Selection Boxes that allow a user to choose (a) the 
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' ^3 databases to which the system has access from which information for assessing availability is to be drawn (b) 
the columns from within their selected databases from which information is to be extracted (c) the row within 
the database that governs the selected information (d) any calculation to be performed on the data (e) the 
threshold for comparison above or below which the seller is available. For example, a seller of industrial 
5 " sToTage space ma7~want to establish" the rule "we are"6rily available to buyers who have spent more than 
$10,000 in this market in the last 4 weeks". Their inputs with reference to the above definitions would be as 
follows (a) Transaction Records (b) purchases in selected markets (c) the present potential buyer (d) total all 
purchases in last 4 weeks (e) if figure is less than $10,000 I am not available. (Because this instruction 
requires access to data other than the seller's own or that is publicly available, this rule would not be 
10 implemented by Availability Management Module 515 without the advance permission of buyers, possibly 
obtained at the time of registration.) Obviously, such a rule could also be presented as a pre-formed option 
stored within Availability Rule Store 550 and market operators may choose to monitor the types of rules 
being set up by sophisticated users and ensure they are then made available as templates to all users. 

15 Likewise, a sophisticated user can input instructions on price calculation by defining any parameters against 
which a purchase request may be measured and indicating his preferred percentage mark up or mark down 
for each. He can then attach those pricing instructions to any period of availability or any rule. 

However, most users are likely to benefit from a menu of pre-constructed types of availability to which they 
20 need only add their choice of inputs defining the conditions under which the rule is to be applied in their 
case. Some examples of pre-constructed rules will now be described with reference to Fig 6 and Fig 7. 

Fig 6 illustrates a table that might be stored within Availability Rules Store 550. It is designed to populate the 
drop down boxes represented in Fig 8 by sections 802a, 802b and 802c. Thus a user calling up the screen 

25 represented by Fig 8 must first select an input for section 802a, the options are shown in Column A of Fig 6 
and the user must select one. That action ensures all the entries in Column B pertaining to the Column A 
selection are then offered in section 802b. Once that selection is made, any text and inputs required in column 
C appear in section 802c. In some cases there may be further clarification required which is summarised in 
Column D and might appear in a pop-up window. By completing the process just described a user is 

30 establishing their own parameters for application of a particular rule, the rule has a reference within 
Availability Rules Store 550, such as the code shown in the left hand column of the table in Fig 6. 

Turning now to Fig 7. This lists the (a) data sources (b) data to be extracted (c) calculation required - if any 
(d) threshold figure to determine availability (e) mandatory Tollow up action to any application of the rule. 
35 This data, also stored in Availability Rules Store 550, is given for each rule in Fig 6 using the Code for each 
rule, again in the left hand column. 



40 



If a rule has been constructed uniquely by a user (a) there is no involvement by Availability Rules Store 550 
in the process (b) it is given its own unique code at the time it is input directly into Seller Database 
Extensions 555. 
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The menu of availability types contained within Availability Rules Store 550 covers many useful options in 
multiple marketplaces. A brief explanation of each pre-formed sample rule in Fig 6 will now be given with 
reference to the code for each rule in the left hand column. Examples of how a particular rule might be used 
by a seller are given in quotation marks. 

Examples of availability rules: 

CP01 enables a seller to be available with different parameters from those in their standard availability. The 
inputs screen for this rule is the same as for standard availability but allow additional sets of parameters to be 
stored. A user may have input rules defining the terms on which they will sell, possibly in the way envisaged 
for GEMs type markets as outlined earlier. Such parameters may include, (a) geographic area in which they 
will sell (b) period of notice with which they will accept jobs (c) minimum or maximum units within one sale 
they will accept, for example the shortest shifts they will work. Any of these factors may carry pricing rules. 
The present option for conditional availability allows a user to create any number of sets of parameters which 
they can attach to periods of availability. ("At these times I will work within a smaller geographic area than I 
have specified for my standard availability and only on shorter shifts and with a 10% increase in my price"). 

P01 to P04 cover characteristics of the buyer that must be met for a seller using each particular rule to be 
available. POl allows a seller to only be available for specified buyers at the selected times ("there are' times 
when the only buyer I will work for is Acme Company"). Similarly P02 allows a seller who is registered on 
the system through an agency to set up times when they are only available to be sold through that particular 
agency's channel to the marketplace. In a market in which buyers are graded according to their track record 
of reliability P03 ensures a seller is only displayed to buyers within certain parameters ("In the overnight 
accommodation market my rooms are only to be displayed to buyers of Grade 4 or above at the times I apply 
this rule.") If buyers are given a profile in which they can define themselves from selections then a seller can 
use P04 to ensure they are only displayed to buyers who have made the appropriate selections in their 
profile; ("I only let my rooms out to buyers who have signified they are vegetarians"). 

P05 and P06 allow a seller to specify they will only be available for sale if they are bundled with at least one 
other seller. Before either option is activated in Seller Database Extensions 555 the other seller(s) named are 
emailed and asked to confirm their willingness to be sold in this way. PQ5 assumes all the grouped 'sellers are 
equals and displays them on the screen represented by Fig 2 as an inseparable offering if both have initiated a 
rule or with one only made available if the other has been selected for purchase if only one of them has 
initiated this rule. ("At these times I am only available for work if my sister is also working the same shift 
because I rely on her for transport"). Alternatively rule P05 can be applied to a separate market, for example 
an operator of video equipment who specifies she is only available for sale if she is purchased together with 
one of her specified video editing suites. In this case she might be displayed to buyers as an option but with 
an icon signifying there must be an additional purchase before a contract can be completed: alternatively, the 
two options could be constructed and priced as one for the buyer. 
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P06 allows the sale of pre-formed teams with a leader, for example in a market for home decorating. ("I will 
only be available for work if Bob Jones is hired as my assistant for the transaction.") This ensures the 
primary seller can be held responsible for the work of a team assembled immediately based on multiple 
availability diaries for perhaps a half day's work; he has signified his willingness to supervise the others in 
histeam in advance. 

P07 is designed for sellers who could only be available for a particular assignment subject to a purchase by 
the seller in another market. ("When this rule is in force 1 am available for periods of work only if a baby- 
sitter who meets all my requirements can be booked in the childcare market to come to my home with the 
cost added to my fee to the buyer.") 

Rule P08 is for delivery drivers, minicab drivers and so on who input an area within which they will travel as 
part of their availability inputs. It enables them to specify geographic areas to which they will additionally 
travel as long as there is reasonable likelihood of selling the return journey. ("I am based in Central London 
but will travel up to 200 miles outside as long as there are at least 10 return journeys an hour from that 
location to London averaged over the day.) 

A problem with binary availability diaries is that a seller can lose a large sale that they could have obtained 
with a small change in availability. For example; a sale for 35 hours of work for which the seller is available 
for only 34 of the required hours will cause them to be rejected as an option in most current systems. Using 
rule P09 a seller can specify for example "I am available within this block of time if time covered by this 
rule makes up no more than 10% of a total purchase".) 

A related problem with availability systems in the art is that a seller who has agreed to be available at the 
times they are displaying availability is vulnerable to a purchase that takes out a small segment of 
availability while rendering the remainder virtually unsaleable. For example, someone who is available for 10 
hours of work each day of Monday through Friday finds they have been booked for five one hour shifts at 
lunchtime each day, thus ruling out the possibility of a full day's work anywhere else. P10 protects against 
this by allowing a user to raise their price, or be rejected as an option, if a particular purchase is going to 
remove less than a given percentage of the period of time covered. In a further embodiment of this rule a 
' seller might be able to specify blocks of time at the beginning or end of a period of availability that may be 
purchased without the rule being invoked while protecting the middle of a period which, if taken by a short 
booking, does the most damage to future sale prospects. 

Pll is designed for groups of two or more sellers where one must not be working at the specified times. 
Again it requires authorisation confirmed by email before entering the record in Seller Database Extensions 
555. ("At this time I am only available for work if my husband is available - but not working - because one of 
us has to look after the children. If I am booked, cancel his availability for that period.") 



28 



Sellers in electronic marketplaces can promote their services in a variety of ways, including the awarding of 
codes, often called vouchers, to potential buyers or to intermediaries authorised to pass them on to potential 
buyers. P12 allows this to be turned into specified times of availability. ("I am a hairdresser and have given 
.out .codes to potential clients at^a fashion show, I am available at the specified times at different pricing to 
5 anyone inputting one of my codes.") 

M01 to MO 4 allow sellers to have their availability determined according to their personal patterns of sales 
activity in the underlying marketplaces. M01 allows a target for income to be input and a timeframe within 
which it is to be achieved. If it has not, at the defined times the seller is available. ("If I haven't made $800 in 
10 sales in the last four weeks I will be available to work this "weekend") M02 applies similar logic to the units 
of sale, for example hours, over a defined period. Both can be pooled targets, for example a husband and wife 
sharing a target for household income through the underlying marketplace. In a further embodiment the seller 
may be able to select a time point at which the availability is to be inserted if they have not achieved their 
goal. 

15 

M03 allows a seller to have the base postalcode, for which distance related pricing is calculated, moved to the 
location of each transaction in the defined period. ("I am a plumber, if I get a job in a certain area I then want 
to be cheapest for other jobs within that area at the time I am due to finish the job.") This rule is dependant 
upon (a) an extended version of the user's weekly availability grid shown in Fig 11 to allow a postalcode or 

20 map reference to be attached to each unit of availability, by default it is populated with the user's base 
location until overwritten by this rule (b) that Asembly of Options Module 424 takes the user's base location 
from the availability grid illustrated by Fig 1 1 rather than from a more static record within Seller Parameters 
Record 431a. Rule M04 is designed for users who wish to add additional availability during which they will 
only work or sell if they have not made a significant sale in an earlier period. ("I will be available to work 

25 tomorrow evening only if I've done less than 2 hours work during the day.") 

Rules E01 to E06 allow a seller to be available depending on events outside of a particular transaction. E01 
ensures a seller is only available at particular times if the number of sellers in one or more of the markets in 
which they have registered to sell fails below average for a specified period. ("I will put my vehicle into the 
30 car hire market if the number of cars available to buyers falls below 75% of the average for this day of the 
week.") E02 applies the same logic for rises above average price levels. 

E03 is again aimed at mobile sellers such as minicab or delivery drivers. It allows them to extend the defined 
geographic area in which they will sell to encompass an adjoining area if that adjoining area has high rates of 
35 sales relative to the number of available sellers. E04 allows a seller to come into the market based on patterns 
in adjoining markets. ("If bookings for coach travel to Scarborough on a Friday rises above average I will put 
my rooms in Scarborough into the overnight accommodation market for that weekend because clearly a lot of 
people are coming here for the weekend.") 
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E05 utilises data within External Variables Datastore 570, allowing a seller's availability to be determined by 
external factors. ("If there is an event listed for the exhibition centre near my home when I have activated this 
rule then I will put my rooms into the overnight accommodation market.") 



5 Rule E06 is intended to work with devices such as mobile phones or GPS enabled personal organisers that 
are able to identify the device's geographic location as a map reference. ("I will be out around Boston all day 
and will do any job with immediate start that fits within my parameters so long as it is less than 0.25 of a 
mile from my location at the time.") 

10 Rules F01 to F03 are designed for sellers who wish to automatically change their offering to the market if 
sales are poor. FOl is for sellers of fixed cost services reliant on multiple buyers who wish to re-sell a part- 
sold offering to another, more economical seller. ("I am offering 52 seats on my coach from Boston to 
Lincoln next Friday, if I have a contract with less than 20 passengers for that journey 24 hours before 
departure I want to see if I can find another provider for them, providing it costs me no more than an 

15 additional 5% on top of what they will pay me, so that I can then try and sell my 52 seats on a more popular 
route.") In the example just given, if the threshold is not achieved, it may be that the passengers are 
transferred to another operator making the journey at the same time, or a more economical minibus is hired 
for their journey. Where this kind of re-selling is a condition of availability Enhanced Availability Store 560 
ensures that fact is displayed to buyers at the time of purchase. 

20 

F02 applies similar logic to breaking up an offering for sale into smaller units. For example an 
accommodation provider may offer 10 rooms on a conference basis but, if they remain unsold 7 days before 
the chosen date, they are to be sold separately. 

25 Rule F03 allows sellers to experiment with their market offering. It simply triggers a switch within Enhanced 
Availability Store 560 to a separate availability rule if there has been no purchase by a given date. At its 
simplest this rule enables a seller to drop their price as a period of availability gets nearer. But it can also be 
used, by attaching additional rules, to widen the area of work or change the willingness to accept certain 
kinds of bookings or change any other parameters discussed in this document. ("If it's Thursday and I 

30 , haven't been booked to work on Monday, I want to drop my base price by 15%, show willingness to work up 
to 10 miles from home and accept evening working".) 

Finally; D01, D02 and D03 allows a user to input provisional availability which is stored by the system but 
which they decide about later. D01 is any availability that the user wants to input but not confirm yet. ("I will 
35 be available at these times if it turns out I don't need to resit my driving exam.") D02 relies on technology 
well known to those in the art that establishes whether a user is currently contactable, for example by 
checking for a mobile phone signal or for recent activity on an online or wireless enabled computing device. 
Using this rule a seller can signify willingness to work immediately just by turning on their cell phone or 
other communications device. 
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D03 is intended to cover times when the user's willingness to fulfil transactions is dependant on a dialogue 
with the buyer. Selecting this options ensures that at the times covered a buyer is shown the seller as a faint 
option but is able to click for a screen containing the seller's chosen contact details. This rule may be most 
effectively used in conju nction with other rules that narrow the range of buyers for whom the seller is 
available. ("During these hours, I am only available to work for Acme Corporation or Grade 6 buyers but 
only if they call me and I accept first.") After a conversation the seller must input the work period in their 
availability diary which generates a contract to be sent to the buyer for online confirmation. A block of 
availability governed by this rule within any wider period of availability covering a potential transaction will 
require that the seller is called regarding the entire transaction. In a further embodiment Enhanced 
Availability Store 560 might store a record of all the buyers who were shown a seller's details under this rule, 
thus a seller can check whom has been given their details through an appropriate screen at any time. 
Additionally, the system may make a charge, to buyer or seller, determined by a figure stored in Operator 
Inputs Datastore 575 for each buyer to whom the details are released. 

The rules outlined above are indicative of the range of potential rules which can make availability conditional 
on (a) any data within a related system of marketplaces (b) any data Availability Server 500 is able to read 
from an external source. It will be clear that many other examples could be offered. Thus, Availability Rules 
Store 550 contains a plurality of pre-formed rules for conditional availability that can be selected by any 
seller. 

Setting up conditional availability rules 

A seller creates their version of a pre-constructed rule for Conditional Availability using a screen like that 
represented by Fig 8. It is generated by Availability Management Module 515 drawing on Availability Rules 
Store 550 and will now be described. 

The process by which a user selects the rule which they wish to add to their personal list using sections 802a 3 
802b and 802c has been described above. As an example, the text shown by Fig 8 assumes rule P01 is being 
input. 

Within section 804 the user is able to stipulate that different parameters and pricing be applied to sales made 
under this rule. Section 804a allows a recalculation of their price, for example an increase by 10% of the 
price they would otherwise charge. This is factored into the process run by technology such as Price 
Construction Module 425 when a sale is under Conditional Availability. Likewise, section 804b allows the 
user to define particular parameters of sale covering for example; travel distance to complete a transaction, 
minimum period of notice or minimum length of shift to be applied to purchases made under this rule. Within 
section 804b users have a choice between (a) their standard availability parameters (b) any other sets of 
parameters they have entered into Seller Database Extensions 555 and named for example using rule CP01 
(c) a new set of parameters they wish to create and attach to this rule. The later choice brings up a parameters 
page requiring inputs for completion. The information in this section is used as the source data for Assembly 



31 



of Options Module 424 in any search on a buyer's requirements for which the present user is covered by 
Conditional Availability. 

Section_806 requires a user to name their version of the rule, this is then used to enable them to identify the 
rule when it is applied to blocks of availability in their diary. 

All the information input into this screen is used to establish a new rule against the user's identity in Seller 
Database Extensions 555. Additionally a user can, if they wish, input preferences that cover the period after 
they have worked or made a sale under the terms of a particular Conditional Availability rule. For example, a 
seller who has worked for a period only because the market in which they sell was particularly short of 
sellers in their area at the time might wish to stipulate that they cancel all availability, or change to a more 
restrictive type of availability, for a specified period at the end of that block of availability. 

Section 810a allows a seller to specify changes to his availability diary within Enhanced Availability Store 
1 5 560, or other availability diary, to be automatically implemented once a sale has been made under the present 
rule. Section 810b likewise allows future potential transactions for a given period to include a price mark up 
that is factored into Price Construction Module 425 for any transaction during that period. 

A seller may also wish to change the way they are contacted about transactions for which they have been 
20 purchased during or after a period of Conditional Availability has resulted in a sale. It may be, for instance, 
that they would like an automated phone call from the system when they get a job because they may be 
paying less attention to their incoming messages after a period of unexpected work. Thus, section 810c might 
present them with contactability procedure options including, in order of how demanding on the user the 
option is deemed, with least demanding first: (a) standard (b) automatic phone call to alert user to a message 
25 (c) call center call with an agent ready to read out details of the job (d) messages sent to multiple devices (e) 
message sent to additional users who will inform the seller of his newly notified assignment. The cost of 
these options may be added to the seller's price displayed to each buyer and then subtracted from the final fee 
by Payment Transfer Module 427. In a preferred embodiment any option selected here may also be applied to 
transactions during the period of Conditional Availability to which it is attached. Thus a user is able to set a 
30 very high threshold for their willingness to work and know that, in the unlikely event that all their conditions 
are met, the system will take additional steps to ensure she receives notification of the sale. 

Section 81 Od allows the user to change their acceptance procedure for transactions over a given period. A 
user might be able to choose from (a) standard acceptance procedure (b) automatic acceptance - that is, they 

3 5 will permit the system to automatically and instantly accept any job meeting all their parameters without their 
confirming it (c) a commitment to accept within a given timeframe, whatever, the length of time the system 
allows, 5 minutes for example. This means they will be taking on any contractual liability which is within all 
their parameters with no option whatsoever to decline or clarify instructions, it may be that only users with a 
solid track record are allowed to engage this option. In a preferred embodiment any option selected here may 

40 also be applied to transactions during the period of Conditional Availability to which it is attached. 
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Clicking on Submit button 612 enters all the information on this screen onto Seller Database Extensions 555 
and generates a new rule against the user's identity. It will thus be clear that a user can input any num'ber of 
variants on a rule, for example having a rule that they will enter the market when the number of sellers in 
5 their chosen market falls below 75% and another specifying they will enter the market when the number of 
sellers in their area falls below 50%. They: can apply either version of the rule to any block of future 
availability they wish. 

10 Fig 9 shows in overview an example of the record for one seller held within Seller Database Extensions 555 
as a result of the seller's interaction with the screen just described. It uses by way of example rules that may 
be input by a seller in the Minicab journeys market. Column 902 gives that version of the rule a number for 
this seller. Column 904 identifies the rule within Availability Rules Store 550, if any, on which this user's 
rule is based. Columns 906, 908 and 910 contain the user's selections taken in from the screen represented by 

15 Fig 8. Column 912 records the actions accompanying that rule taken in from the right hand column of the 
screen represented by Fig 8. Column 914 stores times of any sweeps of data that must be triggered because 
Availability Rules Store 550, or the user's own inputs, shows that the availability is dependant on factors that 
are not (a) specific to a particular transaction (b) stored within External Variables Datastore 570. That is, the 
conditions for availability require checking either (a) at a given period before the block of availability, for 

20 example "I want to un-bundle my offering if it has not been sold 24 hours before the block of availability" (b) 
constantly during the period of availability, for example "I am only available for work at this time if I am 
contactable". Column 916 stores the user's freetext entry giving a name to this version of the rule. 

Sellers are able to apply multiple rules to one block of availability. A set of combined rules is shown in row 6 
25 of the data table represented in overview by-Fig 9. The process for achieving this will be explained later in 
the next section. 

In an alternative embodiment of the process described above, actions to be taken after sales during a period 
of Conditional Availability could be separated from the availability rule under which the seller worked or 
30 made a sale. This is achieved by taking the right hand column of Fig 8 and splitting it into a separate screen 
which allows any user to establish an infinite number of post-sale actions by the system, each of them given a 
name or number either automatically or by the user. For any period of availability under any rule the user can 
then define actions to be applied to their record within Seller Database 431 for a chosen period thereafter. 

35 Inputting availability 

A user who has set up at least one availability rule is able to apply their personalised availability to any 
period of time in the future from the next hour (or other unit of sale) to the maximum period allowed for* 
inputs by the system as stored in Operator Inputs Datastore 575. They input availability using a screen 
generated by Availability Management Module 515 like that represented in Fig 10 which reflects, by way of 

40 example, the screen that might be shown to the user whose rules are illustrated in the table in Fig 9. 
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Section 1002 lists the present user's current rules as read from their record in Seller Database Extens.ons 555. 
Section 1004 allows the list of rules to be increased. Selection box 1004a brings up a blank version of the 
screen represented by Fig 8. Clicking on 1004b brings up the list of existing rules with a request that the user 
5 select one and click Submit, the screen shown by Fig 8 is then delivered already populated with the inputs for 
that rule, any one of which can be changed to create a slightly amended version. 1004c is only displayed to 
users with more than one rule created. Again it brings up a list of the existing rules for this user stored on 
Seller Database Extensions 555 and asks that he highlight the ones he wishes to merge into a new rule. 

10 When merging rules, the user must specify whether the merged rules are to work (a) in combination or (b) 
independently of each other. A combined rule requires that each of the component rules must be satisfied for 
the seller to be available. In the case of independent rules, only one of them need be satisfied, this creates two 
options for the search (a) the rules are applied to the transaction in the order they were assembled at the time 
of merging by the seller and the first one to be satisfied is applied (b) all component rules are searched and 

1 5 the one that creates the most favourable terms for either the buyer or seller is applied, the decision being 
made by the seller. For clarity, (a) is the embodiment assumed in this document. Merged rules can 
themselves be merged to create further combinations. 

Once he has highlighted more than one rule and clicked "Submit" the user is shown a modified version of the 
20 screen represented in Fig 8. In place of sections 802a, b and c it lists the user's names for the rules to be 
modified and requires him to name the new rule as well as, if he wishes, stipulating accompanying pricing 
and selling parameters plus, if he wishes, any actions to be applied to his records after this new rule has 
resulted in a transaction. 

25 For clarification it should be explained that a user can merge multiple versions of one rule. Thus a user may 
have perhaps five different versions of rule P01 ("I am only available for named buyers") with different 
pricing or selling parameters applied to each. They can have all five rules activated for the same block of 
availability with their price and selling parameters determined by which version of the rule is activated, that 
is; which buyer is making the enquiry. Likewise rules that dictate progressive changing of a user's 

30 parameters for sale and pricing can be merged into a sequence so that, using for example rule CP01 and 
setting different activation times, a seller can get progressively cheaper and more widely available as a block 
of availability approaches. This could be particularly useful to sellers of perishable goods. 

In an alternative embodiment of the merged rules function, Availability Management Module 515 might sort 
35 the pricing, selling parameters and actions required for each of the rules being merged and then apply the 
most beneficial to the user of each from any of the rules that form the basis of the new rule. That is, the new 
rule has (a) the highest price construction rules of any of the three rules (b) the most restrictive inputs for any 
one of the selling parameters for any of the rules (c) the most demanding of the actions after a sale. In a 
further alternative embodiment all the stipulations could be merged so (a) the pricing compounds, adding any 
40 mark up specified for each rule (b) the selling parameters become the most restrictive of any input for anyone 




of the parameters for any of the rules (c) all "actions after a sale that are specified for any of the base rules are 
carried out with duplicate instructions ignored. However, a drawback to these two embodiments of the 
merged rules function is that either could easily create unintended consequences for the user when merged. 
Therefore the preferred embodiment is that the user treats the merged rules as a new stand alone rule in terms 
5 of specifying accompanying data or, alternatively that the first of the rules to be merged by the user sets the 
pricing instructions, selling parameters and actions after a sale for the new merged rule. As a further 
alternative merged rules could apply to different conditions within a potential transaction. Thus a user could 
set up rule POl ("I will only be available for nominated buyers") with pricing and parameters attached and 
rule P05 ("I only sell if I am bundled with another named seller") for the same period. The user can specify 
1 0 that rule POl over-rides rule P05 when a nominated buyer is making the enquiry. 

Sections 1006 and 1008 of the screen represented by Fig 10 allow the user to input availability for a specific 
period. 1006a allows him to select a week starting from the present week through to, perhaps, 12 weeks in the 
future/The actual figure is stored in Operator Inputs 'Datas tore 575. If selecting the current week, obviously 
15 no availability can be entered for a time which has passed. That is, the earliest availability that can be input is 
the present time. 

Having selected a week, at 1006b, the user stipulates the maximum number of periods of availability that 
they wish to enter a day. This brings up section 1008 with that number of inputs for each day of the week. By 
20 default all inputs are empty, that is; the seller is assumed to have no availability until he has input a 
willingness to sell at certain times subject to certain rules. 

Within section 1008 the user can input times when he will be available subject to the rule of his choosing. 
For example, for Monday he might select Start: 08.00 End: 14.00 Availability: Rule 2. Then add another 
25 period in the evening which might be Start: 18.30 End: 22.30 Availability: Rule 1; For convenience, having 
input a week of availability the user is able to, using the upper line at section 1010, have those inputs stored 
against his record in Enhanced Availability Store 560. By clicking on the lower line at section 1010 he can 
then have those inputs instantly populate section 1008 for any future week. 

30 As a user is purchased by buyers their availability record is updated by Post Sale Management Module 426. 
If the unit of sale is a block of time, the units of availability that have been purchased are removed, along 
with any required for "buffering", that is; time required to travel to the place of transaction and back again at 
either end of the transaction if appropriate. This is likely to be achieved by a table of time allowed for each 
mile of travel between the seller's base postalcode and the place of transaction. All purchase details are 

35 recorded on Transaction Database 433. By clicking on 1002 the user can view details of their purchases for 
the present week. When all or part of a period of availability has been bought an icon appears against that 
period in section 1008 signifying that it may not be withdrawn; only any unsold remaining availability within 
that period may be cancelled. Otherwise, a user is free to change the times or rules of their availability at any 
time. Finally, Submit button 1004 stores all the inputs in section 1008 within Enhanced Availability Store 
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560. If the unit of sale is physical goods the inventory management software covering this seller's stock is • 
updated and the seller's availability remains unchanged unless they have stipulated otherwise. 

Thus it will be clear that Enhanced Availability Store 560 contains a record of future availability foreach 
user This may be stored as"a series of grids such as"thai illustrated by Fig 11. For simplicity, this illustration 
assumes the unit of availability is an hour, in reality it may be 30 minutes, 15 minutes or in some very fast 
moving markets such as answering telephone services, 5 minutes. It also assumes the market is purely time 
based, if physical goods were being sold supplementary rows of information would link to the approbate 
record in inventory management software. 

Column 1102 lists the days of the week. Row 1104 covers every unit of availability during the day. The grid 
is therefore able to store the rule numbers which currently govern that user's availability at any time in that 
week. «S" in a box signifies Standard Availability, a blank box signifies no availability. 

i There are a number of alternative embodiments to the screen represented by Fig 10 which will be disclosed. 

Combined, ones embodiment: in an alternative version of the present invention the user may be able to attach 
multiple rules to a period of availability without first merging the rules to. create a new rule. Thus a user's 
grid as exemplified in Fig 11 might show in one box that the user is available at that time subject to their 
20 rules 3 4 and 8. This allows the user greater flexibility but has the disadvantages of (a) enabling unintended 
consequences in the merging of rules as discussed earlier (b) requiring verification against possibly 
contradictory or incompatible rules at the point of assembling options for a sale rather than at the point of 
compiling a new rule. 

25 Abbrgyjated code i nnut embodiment : a user may wish to update his availability at a time when he is not near 
a computing device. Once the grid, as shown in Fig 1 1 is understood as the store of his availability he can do 
this with an abbreviated code. Thus by sending a message via Communications Processor 305 that (a) 
identifies the user (b) establishes his right to change his record in Enhanced Availability Store 560, through 
knowledge of a password for instance (c) contains instructions for entering a period of availability, the user is 

30 able to update his availability at any time. For example, he may instruct the system to accept calls from his 
mobile phone number and automatically enter his password. Using a Short Message Service (SMS) facility 
on a mobile phone he might then text: APR 14 - 09.00 - 18.00 - 8. This updates Enhanced Availability Store 
560 to show that on April 14 th his availability will be 9.00 in the morning to 18.00 subject to his. rule 8. In a 
further embodiment, a user may be able to set up very simple codes for remote input into his availability 

35 diary such as "sending the letter A to Communications Processor 305 from my cell phone number signifies I 
am available under my rule 1 for the next half hour", "sending the letter B means I am available under rule 1 
for an hour", and so on. 

. l2:2j: wHi. p| a v embodiment : the creation of colour coded displays is well known to those in the art. A user 
40 might for instance be able to view a version of the grid shown in Fig 1 1 which displays, at a glance, colour 
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bars for different periods of the week with each bar covering a time for which the user is available and the 
colour signifying the rule under which they are available. In a further embodiment the colour coded display 
could be used as a means of inputting availability with the user able to select boxes on the grid using a 
pointing device in ways that are known to those in the art and likewise selecting the rule which is to be 
applied to the newly created block. Periods when the user had been purchased might then be displayed in a 
neutral color such as gray. 

The Advance Sweeps process 

Certain availability rules, for example F01, F02 and F03 might require action by Availability Server 500 
ahead of a period of availability starting. Rules, such as F01 for example, that specify "if X has not been 
achieved by time Y then the terms of my offering change to Z" require a sweep to assess whether X has been 
achieved. This is performed by Sweeps Module 535 triggered by a "sweep required" record with specified 
time for any user stored in Enhanced Availability Store 560. These records are put in place by Availability 
ManagemenfModule 515 when (a) Submit button 1014' in' the screen illustrated by Fig 10- is clicked (b) any 
rule input in section 1008 of said screen contains a "sweep required" flag as for example listed in column E 
of the table shown in Fig 6. The time when a sweep is to be triggered is based on the user's inputs, for 
example "24 hours before the block of availability starts". 

Thus, Sweeps Module 535 constantly sweeps a variety of data sources and changes sellers' offerings, or the 
parameters under which they will sell, within Seller Database 431 or Enhanced Availability Store 560. These 
changed inputs are then searched as normal by functionality such as Assembly of Options Module 424 that is 
seeking to match sellers with a buyer's needs. 

Assembly of options for a buyer 

It should now be clear that (a) Enhanced Availability Store 560 contains a record of availability for a 
plurality of sellers at any specified time with links to inventory management software when goods, rather 
than time, are being sold (b) Seller Database Extensions 555 contains details of the rules under which each 
seller is available if they signify Conditional Availability for a particular unit of sale (c) the present invention 
is able to interface with at least one system of marketplaces in which a buyer may input details of a desired 
purchase and be shown a list of sellers who are willing to fulfil the transaction. 

The process by which a buyer is matched with sellers, any of whom may be only conditionally available, will 
now be described with reference to Fig 12. This process, run by Availability Search Module 520, would in 
the case of "GEMs" type markets described earlier, work in conjunction with Assembly of Options Module 
424. Thus a buyer has input a requirement for purchase, possibly using a screen like that represented by Fig 
1. Assembly of Options Module 424 is able to immediately reject any sellers who are (a) not qualified for the 
market in which the purchase is being made (b) not available for all or part of the transaction period or not 
available with the buffering required for travel to the place of transaction (c) not contactable (d) not in the 
locality required for this buyer's needs (e) lacking the confirmation from inventory software that the seller 
has sufficient stocks to meet the buyer's need if the sale involves goods. The process now described is 




triggered when Assembly of Options Module 424 detects a qualified, contactable seller, potentially available 
to complete a transaction in the required geographical area but with at least one block of Conditional 
Availability within the units of sale required to complete the transaction. Said units can be blocks of time, for 
hire of a person or object, possibly involving a journey or may be physical goods such as produce or 
5 ingredients. The later may be registered by linking individual blocks of inventory to individual periods of 
availability. Using this facility a seller can ensure certain blocks of inventory are associated with a particular 
period of availability. 

At step 1202 Availability Search Module 520 compiles a list of all the blocks of Conditional Availability or 
10 standard availability covered by the present purchase request for the first seller to be searched. This may 
produce ten or more blocks each with its own rule to determine whether the seller is available for this 
particular transaction and how the price is to be constructed for that block. The structure of such a table is 
illustrated in Fig 13 where rows 1302 and 1304 identify the transaction and the seller being searched, column 
V306 is the further number given to each block of availability which must be satisfied for this seller to be 
15 available for this purchase, 1308 and 1310 record the times covered and the appropriate user's rule that 
covers that block, 1312 stores the information regarding whether the user is deemed available for this block 
given the parameters of this purchase, if so column 1314 stores the price per unit for that block and 1316 the 
number of units covered by that block. After compilation, the information held in this record about each 
block of availability may be stored within Historical Datastore 565 and used to produce reports for the seller. 

20 

The ordering of blocks within the table illustrated by Fig 12 could be chronological within the buyer's needs. 
However, where applicable this list might be ordered such that it produces the simplest rules to check first. 
Thus, only if a user has not been rejected by the search on the simpler checks is it necessary to perform the 
more processing intensive checks. This ordering will depend on the complexity of technology required for 

25 live checks, for example if the user has invoked the "I am available if contactable" rule. However, by way of 
example, it might structure blocks of availability by rules based on prioritising the following; (a) any 
availability rule that leads to a simple action such as D03 ("display my availability to the buyer but make it 
dependant on my approval after a conversation".) Where a rule such as this is in force for at least part of the 
transaction and the user is showing standard availability or conditional availability for the rest of the units 

30 required, because it prohibits an immediate sale rule D03 or similar dictates the procedure for this seller for 
the whole transaction (b) any rule such as P12 which requires a very straightforward check ("I will sell to 
anyone with a voucher code I have authorised"), POl ("1 will only sell to named buyers"), P03 ("I will only 
sell to buyers of a certain grade"). Further rules can be ordered based on the complexity of processing 
required to assess whether they permit the user to be available at any time. Rules that are not personalised 

35 versions of those stored in Availability Rules Store 550 but have been composed from scratch by a user are 
likely to be the most demanding. 

Thus, step 1202 of Fig 12 has produced the table described above and populated columns 1306, 1308, 1310 
and 1316. Availability Search Module 520 now moves to step 1204 and reads the first unsearched rule, it 
40 looks this up in the seller's record in Seller Database Extensions 555 which may include a reference to a pre- 
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determined process for the search in Availability Rules Store 550. If the rule was created without a template 
by a user the information will all be contained within Seller Database Extensions 555, this is checked by 
verification at the point the rule was input. 

The process of establishing availability under a particular rule is now begun and will be described with 
reference to columns A, B, C and D within Fig 7 that illustrates the particular requirements for each rule 
stored in Availability Rules Store 550. At step 1208 the data sources pertaining to that rule, for example those 
listed in Column A are accessed. At 1210 the required data, for instance that listed in Column B, is extracted. 
At step 1212, any calculation required, listed in Column C for the example rules given, is performed and the 
results stored temporarily. At step 1214, the data thus produced is compared with the requirements for 
availability such as those stored in Column D of the example rules. This may include constructing a price at 
which the seller will be available for the units covered, said price is entered into the appropriate row of 
column T 3 14 in the table shown in Fig 13. 



Step 1216 reads the results of the comparison as stored in column 1312. If the seller is not available under 
this rule for this block, Availability Search Module 520 checks whether the rule is part of a merged rule 
where the constituent rules apply independently of each other. If so it searches the other constituent rules and 
only proceeds to the next step if none of them can be satisfied. If there is no match of availability 
requirements, at 1232 Assembly of Options Module 424 is instructed that the user is to be rejected by the 
search for sellers willing to meet this buyer's requirements. 

If the seller is available as the result of searching the first block of availability 1220 reads the table shown in 
Fig 13 and ascertains whether there is at least one further block of availability covered by this transaction to 
be searched. If so, steps 1206 to 1220 are repeated for each remaining block. 

If the search shows the seller is available for all blocks of availability covered by this transaction, at step 
1222, all mandatory actions required by any rule invoked are applied to the transaction file within 
Application Processor 306. These rules, if required, are listed in column E of the table shown in Fig 7. At 
step 1224 any choice of action by the seller governing their future availability, contactability, acceptance 
procedure and so on are added to the transaction file. These seller chosen actions are typically input through 
the right hand side of the screen illustrated by Fig 8. Because there may be a plurality of instructions, each 
associated with' a particular block of availability it is preferred that step 1224 include the rationalisation of 
said instructions by acting on only the most extensive of the requirements for (a) curtailing future availability 
(b) changing future pricing, selecting either the biggest rise/fall percentage or the longest running application 
of that rule, such distinction to be stored within Enhanced Availability Store 560 (c) all contactability 
procedures specified under any rule (d) using the acceptance procedure specified against the chronologically 
first block of availability within this transaction. Step 1224 may additionally require information be relayed 
back to inventory management software. 
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At step 1226 the seller is offered to the buyer by Assembly of Options Module 424, that is; the present seller 
becomes one of the options displayed on the screen represented by Fig-2. Price Construction Module 425 
calculates the unit price at which they are to be offered for this transaction by (a) multiplying column 1314 
by column 1316 for each block of availability, including any covered by standard availability, within this 
transaction (b) totalling the 'figures produced (c) dividing the total by the total number of units within the 
transaction. Thus, the complexity of the seller's willingness to comply with the buyer's needs is simplified to 
enable the buyer to make instant per-unit cost/comparisons of the options available for her need. 

Step 1228 waits for a time period stored within Operator Inputs Datastore 575 to see if one or more sellers 
covered by Conditional Availability has been purchased by the buyer. If not, the process ends, possibly with 
the store of information, including that shown in Fig 13. for later reporting to sellers. If purchase is made, at 
step 1230, all the actions stored in the transaction file are implemented by Post Purchase Module 525. The 
selected sellers' inventory and availability diary is updated by having the sold units and associated 
"buffering" removed as previously described and the seller's "My Transactions" list and "My Accounts" 
screens are updated 

Reporting to users 

It is desirable that users of the present invention are able to see an overview of their sales, and potential sales, 
over any given period of time. Likewise, they should be able to understand the extent to which their patterns 
of availability are denying them sales they might have made with less restrictive availability. Reporting to 
users is achieved by Availability Analysis Module 530. Reporting to users should include a screen in which 
the user can define a time period and then see a representation of the grid shown in Fig 11 which is color 
coded according to their personal market activity. That is, in each square of the grid, representing that hour of 
that day for the defined period, there is a different color representing the percentage of (a) time sold (b) 
availability offered under each of the seller's rules (c) time for which no availability was offered. The user 
can then limit the number of rules displayed stipulating for instance "show me all the times I made myself 
available subject to rule 6 with the percentage that resulted in a sale". A seller of goods rather than services 
could see a simpler display perhaps arranged by week, showing offerings under various rules and the 
percentage that resulted in a sale. 

In a further embodiment, by retrieving data in Historical Datastore 565 pertaining to any one seller it is able 
to produce a screen such as that illustrated by Fig 14 for that seller. This screen provides an immediate 
overview of sales made and sales missed over a specified time period. The illustration in Fig 14 assumes the 
seller has been active in a market that (a) grades its sellers and displays them by grade to potential buyers (b) 
displays available sellers in price order with the cheapest in any given grade at the left of the screen. 

Fig 14 is showing, in section 1406, a graphic display of where the present seller was located on every screen 
on which she was displayed to a buyer in the chosen timeframe. The example assumes a seller who has been 
promoted from Grade 4, through Grade 5 to Grade 6 in the specified timeframe. Thus, at 1408, she can see 
that she was displayed 8 times as the cheapest option within Grade 4. Of those 8 bars; 3 are colored black 
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showing that display to a buyer resulted in her being purchased. Thus the user can see at a glance (a) 
whereabouts she has been appearing on buyer's display screens (b) how many displays at each position 
resulted in a purchase. By clicking on any one individual bar in this screen she can bring up a "how your 
price was calculated" screen for that particular purchase. This shows (a) the selling parameters for that 
potential transaction and how each one contributed to the final price displayed (b) the" Completed table" 
represented by Fig 13 if additional availability rules were in force for at least part of the time covered by the 
transaction. Section 1410 represents places on screen where she was below the 4 th cheapest, the actual 
placing shown by a bracketed number attached to the bar representing each transaction. 

Other sections of Fig 14 will now be explained. 1402 allows the user to narrow the data being displayed to 
any combination of certain markets and periods covered by any combination of her availability rules. Section 
1404 allows data to be narrowed to specific times of day and days of the week and a timeframe specified. 
1412a shows the average unit price of all the potential transactions on the screen while 1412b computes the 
percentage "of displayed transactions for which this seller was the cheapest by grade. Section 1412c reports 
the percentage of total availability units for the defined period, as archived in Historical Datastore 565 from 
Enhanced Availability Store 560, that were sold. 

In a non graded market the screen represented by Fig 14 would simply show a ranking for the seller's price 
relative to other available sellers for each transaction. Thus she would be able to see instantly how often she 
had been the cheapest, how often the second cheapest and so on. 

In a further embodiment, Availability Analysis Module 530 might contain the facility to run "what if..." 
scenarios by (a) accessing historic transaction data of buyers' requirements within Historical Datastore 565 
over a given period (b) running an additional seller search and price construction for each relevant buyer 
requirement for a seller who was not available or had different terms of availability at the time (c) comparing 
the additional seller with the actual results of the search at the time to compare their performance with sellers 
who were actually available and determine whereabouts on the buyer's screen they would have been placed if 
they had actually been available. This functionality could be used to confirm the wisdom of new entries by a 
seller. Thus, a seller who plans to start offering new availability at new times can have those times and 
conditions of availability run through perhaps' the last 4 weeks of stored transactions in Historical Datastore 
565. A screen like that shown in Fig 14 can then be produced to show where he would have appeared on each 
buyer display for each transaction in that time for which his inputs would have qualified him. Clearly all 
displays would be gray, as the availability did not exist at the time if could not have resulted in a purchase. 
Once again, he can click on any transaction to see how his price would have been constructed although any 
information identifying the buyer in that actual transaction should be omitted for privacy protection reasons. 

Likewise, a seller who is completely new to the system can input their planned availability and rules and 
immediately be shown where they would have appeared on buyer screens under those terms for actual 
transactions over the previous 4 weeks or other timeframe. Clearly all hypothetical searches of this nature 
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have to factor in a time in advance of the availability when each period of hypothetical past availability was 
presumed to have been input. 

In a further embodiment of this functionality, a setowho is undecided about whether to start seeing in the 
" systemTf marines aisodaled "with the presenUnvention is enabled tolnputlhe times and terms of the 
availability under which they might sell and then see a screen such as that shown in Fig 14 that budds 
progressively from that point on. Their availability is included where relevant by Enhanced Availability Store 
560 and the price they would charge under their terms is constructed but the information is not displayed to 
the buyer and is not reflected in the final ranking of actually available sellers. Instead the seller's screen 
shows where that seller would have appeared on the screen if they had been actually available. In an 
additional embodiment this facility may be used as the basis for conditional availability. Thus a seller is able 
to specify "if I have appeared as the cheapest option for X buyers in Y market in the last hour (or other 
timeframe) I will be available for the following hour (or other timeframe)". 

i In a further embodiment of the seller reporting function, the seller may be able to use a screen like that in Fig 
14 to examine "what if...." scenarios around different types of availability. Thus she could input "change all 
my past rule 17 availability to rule 4" and Availability Analysis Module 530 arrive at a screen showing where 
she would then have been placed on each display to buyers for which she would have been eligible with her 
price calculated. 

) 

Similarly, the seller could change her selection for a particular rule specifying for example, "change the 
threshold for my rule 23 from $100 to $200". Availability Analysis Module 530 would then display her place 
on the screen of any historic buyer requirements for which she would have been eligible. Clearly these 
hypothetical purchases can not show any displays that might have lead to a purchase but might show that, by 
15 changing her rules, she would have shown up as a cheaper option for a lot more potential transactions. To 
make the data displayed more meaningful it might contain only buyer requests that led to a purchase not all 
buyer requests stored in Transaction Database 433. 

Other means of achieving the objectives of the pres ent invention: 
30 It will be appreciated by one skilled in the art that the aims of the present invention could be achieved by 
other means. These might include, the construction of availability rules based on the default assumption of 
availability with sellers then setting the terms under which they are to be ruled out. (For example: "I am 
available unless the number of sellers in my market rises above X% of a historic average".) This is simply 
another way of achieving the aims of the present invention which, in the embodiment described in this 
3 5 document, is based on the default assumption of no availability unless proscribed conditions are found to be 
in force. Similarly availability could be decided by reading external data for example from other websites or 
information channels without compiling it in advance in a unit such as External Variables Datastore 570. 

Alternatively, the binary availability store labelled Seller Availability Record 43 1 b in this document could be 
40 dispensed with and only the store labelled Enhanced Availability Store 560 used. This has the advantage of 
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simplicity but has the drawbacks of (a) requiring the complexity of Enhanced Availability Store 560 to be 
installed from the launch of the marketplace rather than being added later as usage deepens (b) making it 
harder for Availability Server 500 to simultaneously serve multiple marketplaces, each of which may have its 
- own forrnof availability diary already in place. 
5 ^ " ' ' 

Another way of achieving the objectives of the present invention might be to forgo rules constructed in 
advance by users and allow terms of availability to be made up at the point of inputting availability. This is a 
version of the present invention that does not permit the sophistication described in this document. 

10 Other means of allowing sellers in a market to specify a plurality of conditions for availability to sell that 
enable immediate assessment of their willingness to provide for a particular buyer's needs will doubtless 
occur to the qualified person. They are all claimed within the scope of the present invention. 

Additional Embodiments of the present invention ' r ~- 

15 Availability Diary enhancements 

Dynamic buffering embodiment : Rather than applying a uniform formula for "buffering" to cover a seller's 
travel between assignments, Seller Database Extensions 555 might store a default formula but allow sellers to 
input their own. Components of said formula would include (a) time user believes they need to travel a range 
of given distances (b) changes to that formula by percentage based on times of day and days of the week (c) 

20 changes to that formula based on area covered. This facility is particularly useful in a marketplace which 
penalises sellers for non-compliance with transactions they have undertaken. If dynamic buffering is enabled 
the seller is not able to claim unrealistic travel times imposed by the system as a reason for lateness. 

Floating break embodiment : A seller may wish to specify that they need a break in their availability within a 
25 certain period, for example to take a meal 'break, but that they wish to take it when it is commercially 
favourable to do so rather than at a proscribed time. Thus a user might specify they are available from 8.00 to 
19.00 as long as they get a break of an hour between 12.00 and 16.00. If the period of availability results in 
only one assignment this can be achieved by ensuring a match with the buyer's willingness to allow a break 
of the required length within those hours. If the seller is making multiple sales in that period, for example a 
30 minicab driver, Availability Search Module 520 will allow selling of availability only until a required break 
window remains. This embodiment could be turned into a pricing rule in which a user will work in that 
chosen break area but only for an increased price. 

Frivolous availability removal embodiment : the historic availability records of sellers in a system of 
35 marketplaces may be audited to assess whether they have genuinely been attempting to make sales or simply 
displaying availability, that makes it look like they wish to sell, while in reality imposing rules on that 
availability that make it highly unlikely they will make any sales. Such audit might for example be a 
condition of grant payment or to ensure compliance with a condition of investment in their trading activities. 
In an electronic marketplace such audits are likely to be automated. 

40 
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A distinction therefore needs to be made between availability rules that are enabling, that is they make a sale 
more likely and those that are restricting, they make sales less likely than if the seller's normal parameters 
were in force. A grant giver or investor may set sales parameters required of a seller and a minimum number 
of units of availability they demand be offered within a given timeframe. They then need to ensure the seller 
is not using the present invention to restrict sales to a minimum. This can be achieved by categorising rules 
by their effect on availability relative to the user's normal parameters. For the examples given in the present 
document, the categorisation, stored in, Availability Rules Store 550 would be thus: 



RULE 


RULE STATUS 


CP01 


Restricting if narrowed terms, Enabling if wider 
terms 


P01 


Restricting 


P02 


Restricting 


P03 


Restricting 


P04 


Restricting 


P05 


Restricting - (it limits the buyer's choices) 


P06 


Enabling - if the other seller was available at the 
time 


P07 


Status depends if the desired purchase was 
possible 


P08 


Restricting 


P09 


Enabling 


P10 


Restricting 


Pll 


Restricting 


PI 9 


Restricting - if used to exclude non voucher 
buyers 


M01 


Status depends if availability terms were met 


M02 


Status depends if availability terms were met 


M03 


Enabling 


M04 


Enabling 


E01 


Status depends if availability terms were met 


E02 


Status depends if availability terms were met 


E03 


Enabling 


E04 


Status depends if availability terms were met 


E05 


Restricting 


E06 


Restricting (could be used in a no-sales location) 


F01 


Enabling j 
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F02 


Enabling 


F03 


Restricting if narrowed terms, Enabling if wider 
terms 


D01 


Restricting j 






D02 


Restricting 


D03 


Restricting 



In a further embodiment the user might be advised if they are entering what will be deemed frivolous 
availability at the time they enter it, that is when they click the Submit button on the screen represented by 
Fig 10. 

5 

Display control embodiment: A vailability rules input by means of a process such as that illustrated within Fig 
. 8 might include the means to further dictate how a seller is displayed to potential buyers. For example, a 
seller may be allowed to stipulate the market sectors in which the availability applies exclusively. For 
example they may wish to have very limited availability in one market and merge that with a rule giving 
10 them broad availability in others. Additional rules may then be applied to potential sales in certain market 
sectors only. 

Tentative sale embodiment : a seller may wish to only commit to a sale once a required number of buyers 
have been recruited. For instance, a tutor selling language lessons may only consider it worthwhile running 
15 the proposed classes if a minimum of ten students are signed up. This embodiment allows her to input 
tentative availability. This requires her to (a) specify broad details of the service on offer and its dates/times 
(b) specify the minimum number of buyers required (c) input the maximum number of buyers to be accepted 
(d) define the time at which the offer will be withdrawn if the required number of buyers have not been 
found. 

20 

Tentative availability that meets a buyer's needs appears as a separately colored option on the screen 
represented by Fig 2. If selected it might reveal the details of (a) above and display (b) (c) and (d) together 
with the present number of committed buyers. A buyer can then input a commitment to purchase assuming 
the sale is eventually offered. When point (d) is reached he is informed of the outcome. This embodiment 
25 might be most useful in conjunction with the incremental pricing option listed below to encourage early 
buyers. 

Price construction enhancements 

Price undercutting embodiment : A seller may wish to define their availability in terms of their pricing 
30 relative to the rest of the market. For example: "If I haven't worked in the previous 2 days I wish to start 
being the cheapest seller (or within X% of the cheapest) on every screen of buyer options on which I appear". 
Market operators may take the view that such a rule is not permissible because (a) it can result in circular 
arguments, if everyone is determined to be cheapest there can be no price with which to begin calculations 
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(b) sellers may find themselves unintentionally committed to transactions at prices they had not foreseen 
because of another seller's anomalous price instructions (c) the means of constructing price in a "GEMs" 
type marketplace as described allows pricing that accurately reflects the cost and desirability of a particular 
transaction for a particular seller, there is little point in being the cheapest if it costs the seller more to fulfil a 
5 transaction than someone else who is nearer and better equipped. 

However, markets with advance price construction based on multiple parameters can allow undercutting as 
an over-riding principle of price construction. A taxi driver who is commissioned for a journey from X to Y 
for example may then want Price Construction Module 425 instructed to automatically undercut all other 

10 sellers for a return journey that he is going to have to make anyway. Clearly undercutting has to be limited to 
avoid the problems above but it might be allowed as a rule stored in Seller Database Extensions 555 by a user 
that can only be applied if (a) fewer than X% of a pool of sellers for a given buyer's requirement are allowed 
to invoke the facility (b) priority for the facility is determined by the first sellers to apply that rule to the 
relevant block of availability (c) the price differential between the lowest' price constructed without this 

1 5 facility and the price generated by a user of this facility is determined by the relevant seller in advance (d) if 
more than one seller on a list of options is using this facility they are all calculated on the basis of the 
cheapest seller not using this facility, they do not drop in price relative to each other. In a further embodiment 
of this option sellers may be permitted to undercut prices in an adjoining market; for example, a minicab 
driver could set her pricing for long distance hires relative to the cheapest price that would be charged in the 

20 coach journeys market for the same journey. 

Payment among sellers emb odiment: In cases such as rule P05 where two or more sellers are only available 
as a grouped purchase Seller Database Extensions 555 might store details of a levy to be paid to one of the 
sellers by the others. Typically this would be used if one seller provided transport to the others. The levy 
25 could be calculated on the basis of distance and deducted automatically when payment from the buyer was 
received. 

Personalisation of price increases embodiment : sellers may be allowed to increase or decrease their rate 
based on certain parameters by actual currency amounts rather than percentages of the base price. However, 

30 this would make it less easy to for them to coherently manipulate overall prices by changing the base price. 
Similarly 'users may be enabled to set their own increments for price calculation. For example a user could 
specify; "If I get less than 27 minutes notice of a job I charge an extra 12%", "If I get less than 43 minutes I 
charge an extra 18%" and so on. Additionally users may be given the facility to add a flat rate "call out" 
charge to their rate that is applied to each assignment and added to the price calculated from their stored 

3 5 information. 

Cancellation pricing embodiment : Sellers may be given the means to set a cancellation charge as part of any 
period of availability, possibly based on a sliding scale that defines the percentage of the fee to be charged 
relevant to the notice with which the job is cancelled. A seller is cancelled before or during the period of a 
40 transaction by a buyer's inputs. The seller may then have the availability and buffering that was removed to 
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allow them to fulfil that transaction reinstated in Enhanced Availability Store 560 so they can be immediately 
bought by another buyer. 

In a further embodiment of a cancellation function, the seller could be released back into the market and the 
amount they subsequently earn in the restored availability totalled^ the" original buyer is then billedTor any 
shortfall in earnings or the shortfall plus an additional fee to compensate for inconvenience. It may be that 
automated price undercutting is allowed under these conditions as it is in both buyer and seller's interests that 
a new buyer is found promptly. In an additional embodiment a seller's cancellation fees might be calculated 
at the point of cancellation based on the likelihood that they will be able to re-sell their offering. This would 
factor in (a) the number of units of time before the reinstated availability starts as a percentage of the number 
of units of time between the original booking and the start time of the transaction (b) the historic frequency of 
purchases in that market in the area in which the seller is willing to transact at that time over a given period 
as a percentage of the same figure applied to all markets and all geographical areas covered by the underlying 
system of marketplaces in the same' timeframe, if relevant purchases are frequent-the cancellation rate will be 
lower (c) the number of available sellers in the relevant market/area at the time of cancellation as a 
percentage of historic averages over a given timeframe, if there are few sellers, the cancellation rate falls. 
Data for (b) is extracted from Transaction Database 433. Data for (c) is extracted from Enhanced Availability 
Store 560 and compared with historic data contained within Transaction Database 433. Thus, by way of 
example, a cancellation charge for a particular assignment might be a weighted version of the following 
formula using the three characteristics above: price that was to have been paid for the assignment multiplied 
by (100% - (a)), multiplied by (100% - (b)) 5 multiplied by (c). 

Standby-availability embodiment : There are times when a user wishes to book buyers 5 offerings not knowing 
if they will ultimately be required or not. If a fee is paid for thus reserving a particular seller, this can work to 
the advantage of both buyers and sellers because sellers can effectively be paid for nothing more than taking 
their availability out of the market pending a decision by the buyer. Thus Seller Database Extensions 555 
might facilitate users specifying times for which they are willing to be put on standby subject to their 
requirements for (a) charge to the buyer (b) the period by which they must be either confirmed or released 
from a period of stand-by (c) any automated actions the user wishes the system to take if they are released 
without being purchased. This assumes that, if the buyer exercises his option to purchase the provisionally 
booked availability, the seller is bought at the rate they would have charged for a given period of availability 
subject to all other pricing rules in force at the time of purchase. 

Dynamic construction of seller parameters embodiment : Sellers in an arena such as the "GEMs" type markets 
described earlier construct their price around certain pre-defmed parameters of a buyer's need such as 
distance to be travelled, period of notice, length of work shift and so on. This enables a price to be 
constructed at the point of buyer enquiry that immediately reflects a particular seller's willingness to fulfil a 
particular requirement. Sellers may wish to add to this list by submitting a question relevant to their market 
and the suggested increments against which price can be increased or decreased, by the individual seller. 
These potential questions, stored in Seller Database Extensions 555 for that seller can become a condition of* 
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a seller's availability for certain assignments, are then offered to buyers who wish to engage with a wider 
range of sellers. 

For example a seller in the camera repairs market might pose a range of questions such as (a) has the camera 
5 been exposed to a hostile environment such as water or dust? (b) does the camera fail to wind film? (c) is 
light leaking into the film chamber? The user can then insert a percentage of base price to be added to or 
subtracted from the price if the buyer answers "Yes" to a particular question. Such questions are least 
demanding of buyers when they are merged into a coherent list against which any seller can set up pricing 
parameters. It may therefore be that when certain conditions are met Sweeps Module 535 will forward the list 
10 of unclassified questions in a market to a high grade or other seller in the relevant market with the request 
that they turn them into a coherent list, possibly in return for a payment. The returned list is then incorporated 
into Availability Rules Store 550. Conditions to be met might include (a) a threshold number of outstanding 
question lists in one market (b) value of said market (c) presence of a suitable user who has indicated a 
willingness to perform" this function. ' ... ........ 

15 

Incremental pricing embodiment : a seller who requires multiple buyers to enable a sale, such as a coach 
travel company, might wish to specify that their first 10 seats be sold at price A, the next 10 at price B and so 
on. Selection of price change points and the new price can be made by Drop Down Box. If this is used to 
determine only the base price, before calculations made by the present invention that might for example, 
20 factor in the desirability of each potential passenger to the operator, sophistication in price construction is 
immediately available. In a further embodiment the price change points could be relative to the beginning of 
the availability block. 

Single se ller embodiment: with slightly altered screen displays, the present invention could be used by a 
25 single seller who has multiple buyers. The seller would thus be able to control their interaction with their 
buyers more precisely. For example, a driving instructor selling hour long lessons might choose to be 
available under multiple versions of rule P01, when a new student is enrolled that student is allocated a set of 
parameters, including price, under which they can buy lessons. By merging all these rules independently, the 
instructor might then specify that she is available for lessons at certain times, each student can call up a 
30 display of still available lesson times with the price at which each can be bought. To make the seller's life 
simpler the present embodiment might include one screen within which they can (a) enter a new student's 
details (b) attach any number of rules to that buyer '(c) remove students with whom they no longer have a 
relationship. 

35 Descriptions of the system above have assumed a wide ranging system of markets. The invention applies 
equally to a narrow range of markets, for example a market for secretarial services with sectors covering 
medical, legal, educational and commercial secretaries as a system of markets. 

In above described embodiments of the system the Internet, and more specifically web technology, is used 
40 for communication between a central computer system and the buyers and sellers. However, it is not 
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necessary to implement the invention .using the Internet and the system may, for example, be implemented on 
local or wide area networks, wireless mobile communications networks, cable tv networks and the like. 
Similarly, the terminals used by the buyers and sellers for communicating with the central computer system 
may comprise mobile phone handsets, personal digital assistants, inter-active televisions and the like. 
5 Likewise, as it is well known to those skilled in the art, the processing for performing the functions described ' 
above may be shared between machines in ways other than that shown in the illustrated embodiments. 
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No doubt many other effective alternatives will occur to the skilled person and it will be understood that the 
invention is not limited to the described embodiments and encompasses modifications apparent to those 
skilled in the art lying within the spirit and scope of the claims appended hereto. 
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CLAIMS: 

1. A transaction management system for managing the purchase of a product or service by a buyer 

from a seller, the system comprising: . _ .... 

5 " - Tdata store for storing seller data comprising; for each of a plurality of sellM seller identifier; 
a program store storing processor implementable instructions; and 

a processor coupled to the data store and to the program store for implementing the stored 
instructions, wherein the stored instructions comprise instructions for contro.ling the processor to implement 
a seller interface to receive seller offer data from a seller, the seller offer data including an availabihty record 
10 for a product or service offered for sale, the availability record defining a plurality of periods of conditional 
availability, each period of conditional availability having an associated set of conditions under wh.ch the 
product or service is or is not available. 

2. The system of claim 1, wherein the data store is further for storing the seller offer data received 
1 5 from a plurality of sellers by the seller interface. 

3. The system of claim 1 or 2, wherein availability of the product or service during the periods of 
conditional availability is dependent on data internal or external to the system. 

20 4 The system of any one of the preceding claims, wherein the seller interface is further implemented 

to receive a plurality of sets of conditions from a seller, each set of conditions comprising an availability rule. 

5. The system of claim 4, wherein the data store is further for storing the availability rules received 
from a seller by the seller interface. 
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6. The system of claim 5, wherein the data store is further for storing a plurality of predefined 

availability rules. 



7 The system of any one of claims 4 to 6, wherein the seller interface is implemented to facilitate 
30 construction of the availability record for a product or service by receiving periods of conditional availability 

associated with availability rules from the seller. 

8 The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a buyer 

3 5 purchasing at least one linked product or service. 

9 The system of claim 8, wherein the at least one linked product or service is offered for sale by at 
least one different seller, and wherein the seller interface is further implemented to notify the at least one 
different seller that the products or services have been linked. 
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10. The system of any one of- the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on at least one 
linked product or service being available to the seller. 

11. The system of any one of the preceBing claims, wherein the availability record for a~product or • 
service defines that availability in at least one period of conditional availability is dependent on a purchase 
comprising less than a defined amount of the period of conditional availability. 

12. ■ The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a purchase 
comprising more than a defined amount of the period of conditional availability. 

13. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period . of conditional availability is dependent on a Jinked 
product or service not being purchased fof the period of conditional availability. 

14. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on the seller's 
revenue or profit in a preceding timeframe. 

15. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a travel 
distance associated with the buyer from a preceding buyer location. 

T6. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period' of conditional availability is dependent on a travel 
distance associated with the buyer from a current location of the seller. 

17. The system of claim 16, wherein the system is arranged to determine the current location of the 
seller based on signals received from a global positioning system device or a cellular telephone device. 

18. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a defined 
reduction in the availability of products or services in a defined market 

19. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a defined rise 
in the price of products or services in a defined market. 
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20 The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on the seller 
having sold a defined number or value of linked goods or services by a defined time before the period of 
conditional availability begins. ...... 

21. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a linked 
product or service being unsold at a defined time before the period of conditional availability begins, the 
linked product or service being a larger quantity of the product or service offered for sale. 

22. The system of any one of the preceding claims, wherein the availability record for a product or 
service defines that availability in at least one period of conditional availability is dependent on a defined 
increase or decrease in the price of the product or service. 

15 23. The system of any one of the preceding claims, wherein the availability record for a product or 
service further defines a plurality of periods of unconditional availability or unconditional unavailability. 

24. The system of any one of the preceding claims, wherein the seller interface is implemented across 
the Internet. 

20 

25. The system of any one of the preceding claims, wherein the seller interface is implemented across a 
cellular telephone network. 

26. The system of claim 25, wherein the availability record is based on text messaging such as the SMS 
25 system received by the seller interface across the cellular telephone network. 

27. The system of any one of the preceding claims, wherein the stored instructions further comprise 
instructions for controlling the processor to implement a buyer interface to: 

receive a purchase enquiry from a buyer, the purchase enquiry including a required period of 

30 availability for a product or service; 

output seller offer data for a plurality of sellers able to provide the product or service for the 

required period of availability; and 

receive a purchase request from the buyer accepting an offer. 

35 28. The system of claim 27, wherein the buyer interface is implemented to only output seller offer data 
for products or services that are conditionally available if the associated set of conditions are met. 

29. The system of claim 28, wherein the system is arranged to determine whether the set of conditions 
are met at a predetermined time before the associated period of conditional availability. 
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30. The system of claim 28, wherein the system is arranged to determine whether the set of conditions 
are met when a purchase enquiry for the products or services is received form a buyer. 

31. The system of any one of claim 27 to 30, wherein the buyer interface is implemented over the 
Internet. 

32. The system of any one of the preceding claims, wherein the seller interface is further implemented 
to indicate the current availability of the seller's products or services during periods of conditional 
availability. 

33. The system of any one of the preceding claims, wherein the seller interface is further implemented 
to indicate the potential availability of the seller's products or service during periods of hypothetical 
conditional availability. 

34. The system of claim 32 or 33, wherein the seller interface is further implemented to indicate the 
availability of other sellers' products or services. 

35. The system of any one of the preceding claims, wherein the system is for managing the purchase of. 
products or services by one buyer from a plurality of sellers. 

36. A method for managing the purchase of a product or service by a buyer from a seller, the method 
comprising: 

storing in a data store storing seller data comprising, for each of a plurality of sellers, a seller 
identifier; and 

implementing a seller interface to receive seller offer data from a seller, the seller offer data 
including an availability record for a product or service offered for sale, the availability record defining a 
plurality of periods of conditional availability, each period of conditional availability having an associated set 
of conditions under which the product or service is or is not available. 

37. The method of claim 36, further comprising storing in the data store the seller offer data received 
from a plurality of sellers by the seller interface. 

38. The method of claim 36 or 37, wherein availability of the product or service during the periods of 
conditional availability is dependent on data internal or external to the system. 

39. The method of any one of claims 36 to 38, wherein the seller interface is further implemented to 
receive a plurality of sets of conditions from a seller, each set of conditions comprising an availability rule. 



40. The method of claim 39, further comprising storing in the data store the availability rules received 
from a seller by the seller interface. 
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41. The method of claim 40, further comprising storing in the data store a plurality of predefined 
availability rules. 

42. The method of any one of claims 3? to 41, wherein the seller interface is implemented to facilitate 
construction of the availability record for a product or service by receiving periods of conditional availability 
associated with availability rules from the seller. 

43. • The method of any one of claims 36 to 42, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a buyer purchasing at 
least one linked product or service. 

44. The method of claim 43, wherein the at least one linked product or service is offered for sale by at 
least one different seller, and wherein the seller interface is further implemented to notify the at least one 
different seller that the products or services have been linked. 

45. The method of any one of claims 36 to 44, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on at least one linked 
product or service being available to the seller. 

46. The method of any one of claims 36 to 45, wherein the availability record for a product or service 
defines that availability in at" least one period of conditional availability is dependent on a purchase 
comprising less than a defined amount of the period of conditional availability. 

47. The method of any one of claims 36 to 46, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a purchase 
comprising more than a defined amount of the period of conditional availability. 

48. The method of any one of claims 36 to 47, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a linked product or 
service not being purchased for the period of conditional availability. 

49. The method of any one of claims 36 to 48, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on the seller's revenue 
or profit in a preceding timeframe. 

50. The method of any one of claims 36 to 49, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a travel distance 
associated with the buyer from a preceding buyer location. 



51. The method of any one of claims 36 to 50, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a travel distance 
associated with the buyer from a current location of the seller. 

52. The method of claim 51, wherein the system is arranged to determine the current location "of the 
seller based on signals received from a global positioning system device or a cellular telephone device. 

53. The method of any one of claims 36 to 52, wherein the availability record for a product or service 
defines that availability in at least one period. of conditional availability is dependent on a defined reduction 
in the availability of products or services in a defined market. 

54. The method of any one of claims 36 to 53, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a defined rise in the 

' price of products or services in a defined market. i - . . . , 

55. The method of any one of claims 36 to 54, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on the seller having sold 
a defined number or value of linked goods or services by a defined time before the period of conditional 
availability begins. 

56. The method of any one of claims 36 to 55, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a linked product or 
service being unsold at a defined time before the period of conditional availability begins, the linked product 
or service being a larger quantity of the product or service offered for sale. 

57. The method of any one of claims 36 to 56, wherein the availability record for a product or service 
defines that availability in at least one period of conditional availability is dependent on a defined increase or 
decrease in the price of the product or service. 

58. The method of any one of claims 36 to 57, wherein the availability record for a product or service 
further defines a plurality of periods of unconditional availability or unconditional unavailability. 

59. The method of any one of claims 36 to 58, wherein the seller interface is implemented across the 
Internet. 

60. The method of any one of claims 36 to 59, wherein the seller interface is implemented across the 
cellular telephone network. 



61. The method of claim 60, wherein the availability record is based on SMS text messages received by 
the seller interface across a cellular telephone network. 
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62 The method of any one of claims 36 to 61, further comprising implementing a buyer interface to: 

receive a purchase enquiry from a buyer, the purchase enquiry including a required period of 

availability for a product or service; ^ 

output" seto- offer " dita"^ "plurality of -sellers able to pro-vide "the product or iervice for the 

required period of availability; and 

receive a purchase request from the buyer accepting an offer. 

63. The method of claim 62, wherein the buyer interface is implemented to only output seller offer data 
for products or services that are conditidnally available if the associated set of conditions are met. 

64. The method of claim 63, wherein whether the set of conditions are met is determined at a 
predetermined time before the associated period of conditional availability. 

65. The method of claim 63, wherein whether the set of conditions are met is determined when a 
purchase enquiry for the products or services is received form a buyer. 

66. The method of any one of claim 62 to 65, wherein the buyer interface is implemented over the 
Internet. 

67. The method of any one of claims 36 to 66, wherein the seller interface is further implemented to 
indicate the current availability of the seller's products or services during periods of conditional availability. 

68. The method of any one of claims 36 to 66, wherein the seller interface is further implemented to 
indicate the potential availability of the seller's products or service during periods of hypothetical conditional 
availability. 

69. The method of claim 67 or 68, wherein the seller interface is further implemented to indicate the 
availability of other sellers' products or services. 

70. The method of any one of claims 36 to 69, wherein the method is for managing the purchase of 
products or services by one buyer from a plurality of sellers. 

71. A computer software product arranged to cause a computer to execute the method of any one of 
claims 37 to 70. 

72. A computer readable recording medium having encoded thereon at least one program for 
performing the method of any one of claims 37 to 70. 
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A TRANSACTION MANAGEMENT SYSTEM AND METHOD 



Abstract 

A transaction management system manages the purchase of a product or service by a buyer from a seller. The 
system comprises: 

a data store for storing seller data comprising, for each of a plurality of sellers, a seller identifier; 
a program store storing processor implementable instructions; and 

a processor coupled to the data store and to the program store for implementing the stored 
instructions, wherein the stored instructions comprise instructions for controlling the processor to implement 
a seller interface to receive seller offer data from a seller. The seller offer data includes an availability record 
for a product or service offered for sale, the availability record defining a plurality of periods of conditional 
availability, each period of conditional availability having an associated set of conditions under which the 
product or service is or is not available. ' "' ' ' '* - 
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Fig. 1 



In which market do you with to purchase? 

| Temporary work (\/| 

Please defin e your needs from this list: 

j Secretarial \\/\ 



Period of work 



Start date 



End date 



ia^lEEg^lEiMsWHglsJEEg^ 



ma 



If this is not a solid period of work days please specify 
days to be worked per week: 
Mori Tues Wed Thur Fri Sat Sun 

o o o o o o o 



Daily work times 
Start |14.30M 



End I17.30M 



Postalcode of place of work | M1 M 



CANCEL 



SUBMIT 



Fig. 2 
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There are 15 sellers available for your specific booking 



Ron Lanz 
$19.38 



Sam Small 
$19.56 



Jane Harris 
$21.07 



Sec. from 
XYZ agency 
$22.08 



Hazel Dean 
$22.89 



Sec. from 
ABC agency 
$19.45 



Mary 
Howard 
$20.43. 



Ket Chan 
$21.56 



Julie Good 
$22.10 



Sue Potter 
$27.90 



Ally Wilmot 
$19.48 



June James 
$20.45 



Fiona Foo 
$22.00 



Lesley Vine 
$22.10 



Anne Scully 
$35.98 



Click on any selier(s) to make your 
selection. Then press submit. 



SUBMIT 



Fig. 3 
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MS 



BTS 



MOBILE PHONE 
NETWORK 



COMMUNICATIONS 
INTERFACE 



COMMUNICATIONS 
PROCESSOR 



I 



305 




APPLICATION 
PROCESSOR 



V 



306 



308 




307 



SERVICE PROVIDER 
TERMINAL 



DATA STORE 



301a 



\ 



SELLER TERMINAL 
301b 



SELLER TERMINAL 




BUYER TERMINAL 

T 

302b W~~ 

LB 

BUYER TERMINAL 



\ 



300 
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I 



305 



Communications processor 



306 



Seller registration 



Application processor 
|7 421 



Buyer registration 



irYn / 



V 



422 



423 



Transaction 
management 

/ 424 

Assembly of [_ 

options r 



Post sale 
management 



/ 



425 



Price Construction 



426 



User maintenance 



J 428 



Payment transfer 

^ 



427 



T 



307 



431 



Datastore 



Seller database 



431 a \ 



431b \ 



1 
( 



Seller parameters 
record 

Seller availability 
record 



431c \ 



Seller contactability 
record 



/ 



432 



Buyer database 



1/ 



L 



433 



Transaction database j 



L 



434 



Market rules database 



I) 
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303 




COMMUNICATIONS NETWORK 



/ 



500 



AVAILABILITY 
SERVER 




304 



AVAILABILITY 
APPLICATION 
PROCESSOR 



V 



505 




510 



AVAILABILITY DATA 
STORE 



COMMUNICATIONS 
INTERFACE 



COMMUNICATIONS 
PROCESSOR 



^305 1 




I 



306 



APPLICATION 
PROCESSOR 



308 



SERVICE PROVIDER 
TERMINAL 



/ 



307 



DATA 
STORE 



Fig 5b 
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/ 



500 



Availability Server 



505 



Availability Application Processor 



AVAILABILITY MANAGEMENT 
MODULE 



AVAILABILITY SEARCH MODULE 



POST-PURCHASE MODULE 



/ 5 ^ 5 
^520 
525 



AVAILABILITY ANALYSIS MODULE 



/ 

^530 



SWEEPS MODULE 



/ 



535 



SELLER MONITORING MODULE 



540 



Availability Datastore 



510 



AVAILABILITY RULES STORE 



SELLER DATABASE EXTENSIONS 



ENHANCED AVAILABILITY STORE 



HISTORICAL DATASTORE 



EXTERNAL VARIABLES DATASTORE 



550 

I 

555 



560 



565 

I 

570 



OPERATOR INPUTS STORE 
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CODE 
FOR 
THIS 
RULE 


Column A 


Column B 


Column C 


Column D 


Column E 




My 
willingness 
to sell at 
the defined 

times is 
dependant 
on: 


Particularly 


Under this rule 1 am oniy available 
if... 


My specific 
requirements are: 


Mandatory actions 
triggered by this 
rule 


CP01 


Changed 
parameters 
for my 
availability 


TAKES USER TO A NEW PARAMETER INPUT PAGE 


User must complete 
a further Selling 
Parameters screen 


P01 


The 

pariicular 
purchase 


Who the buyer is 


...the purchase is by one of the 
following buyers: 
[SELECT BUYERS] 










The agency / 
portal 

representing the 
buyer 


...the purchase is by a buyer from 
one of the following agencies / 
portals: 

[SELECT AGENCIES / PORTALS] 




Obtain authorisation 
from administrators * 
of selected 
agencies /portals if 
there is no existing 
link such as seller 
registration through 
that agency /porta! 


P03 




Grade of buyer 


the buyer is [ABOVE or 
BELOW] grade [SELECT GRADE] 






P04 




Profile of buyer 


....the buyer has indicated in their 
profile that they are.... 
[OFFER PROFILE OPTIONS] 






P05 




Other people I 
want to sell with 
as equals 


...the buyer will hire me as a 
package with [SELECT MARKET] 
[SELECT SELLER] 
(this can include multiple options 
plus "or" options with a minimum 
and maximum number defined) 




Obtain authorisation 
from other seller(s) 


P06 




Other people I 
want to work with 
as a forma! team 
for a sale 


...the buyer will hire a team to work 
for me selected from: [SELECT 
SELLER] 

(this can include multiple options 
plus "or" options with a minimum 
and maximum number defined) 




Obtain authorisation 
from other seller(s) 


P07 




I need to ! 
purchase 
something before 
I can offer to sell 


...the price paid by the buyer 
includes my requirement in the 
following market sector [SELECT 
SECTOR]. Thecostis[TOBE 
ADDED TO MY PRICE F OR THE 
SELLER or NOT ADDED TO MY 
PRICE FOR THE SELLER] 


Requirement 
defined by (a) 
overlap with 
booking (b) 
location -if not 
place of sale (c) 
define minimum 
grade" of seller 
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P08 




If I will travel 
during the 
transaction, ami 
likely to get a 
paired sale to 
bring me back 
near mybase? 


....there needs to be a likelihood of 
at least [SELECT NUMBER] return 
purchases per [SELECT 
TIMEFRAME eg "hour"] ihatwould 
bring me back to my base work 
area 




Verification: only 
one of geography 
dependant rules 
(eg: P08, E03 and 
M03) can be in 
force at any time. 
They can not be 
merged. 


P09 




only if this 
availability is 
required to 
enable a large 
purchase 


at least [SELECT 
PERCENTAGE] of the purchase is 
covered by my other availability 






P10 




I will lose too 
much potential 
for other sales by 
being bought for 
a particular 
purchase 


...a particular purchase takes more 
than [SELECT PERCENTAGE] of 
my availability within Any given 
[SELECT TIMEFRAME eg "day"] 


If this rule is 
activated [I AM 
NOT AVAILABLE 
or I AM 

AVAILABLE AT A 
PRICE 

INCREASE OF 
(SELECT)%] 




P11 




I can only be 
available if 
someone else is 
NOT working 


[SELECT SELLER] is not 
working at the time of the purchase. 
(NB: can include "or" options) 
Cancel other seller's availability if 
you are purchased? 




Obtain authorisation 
from other sellerfs) 


P12 




I will sell to 
anyone who has 
a voucher I have 
approved 


....the codes input by the buyer 
match [INPUT CODES] each 
voucher can be used for [SELECT 
NUMBER] of purchases or voucher 
expires on [DATE]. Vouchers apply 
to [SELECT MARKET]. Under this 
rule [I AM ONLY AVAILABLE FOR 
VOUCHER HOLDERS or MY 
ADDITIONAL PARAMETERS AND 
PRICING FOR VOUCHER 
HOLDERS IS AS DEFINED 
BELOW] 






M01 


My market 
activity 


My recent 
earnings 


.... my earnings in the period since 
[DEFINE TIMESPAN - eg "4 . 
weeks" OR DEFINE START 
DATE/TIME] have been [LESS or 
MORE] than [DEFINE AMOUNT] 


I want my targets 
pooled with 
[SELECT 
SELLER] 


If poo led targets 
selected the 
authorisation of the 
other seller must be 
obtained by email. 


M02 




My recent units 
sold 


.... my units of sale in the period 
since [DEFINE TIMESPAN - eg "4 
weeks". OR DEFINE START 
DATE/TIME] have been [LESS or 
MORE] than [DEFINE NUMBER OF 
UNITS] 


I want my targets 
pooled with 
[SELECT 
SELLER] 


If pooled targets 
selected the 
authorisation of the 
other seller must be 
obtained by email. 


WI03 




Keeping travel 
between 
bookings to a 
minimum by 
moving my base 
postalcode to the 
location of each 
booking 


...my base postalcode after a 
booking is moved to the location of 
thatbooking assuming an average 
time I spend at the final location of 
my jobs of [SELECT TIME PERIOD 
eg "1 hour"] 




Verification: only 
one of geography 
dependant rules 
(eg;.P08, E03 and 
M03) can be in 
force at any time. 
They can not be 
combined. 
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M04 




i have been 
available but not 
been purchased 
in the preceding 
period 


...I worked less than [DEFINE 
PERIOD eg M hours"] in the 
[DEFINE PERIOD eg "12 hours"] 
before this period. Switch to this 
rule [DEFINE PERIOD eg "3 hours"] 
before availability starts 




Advance sweep is 
triggered at the 
appropriate time 
with change to 
Availability diary if 
no saies met 


E01 


Events 
outside 
any 

particular 
transaction 


Number of 
available sellers 
in my market 
dropping 


....the marketin my area fells below 
[SELECT PERCENTAGE] of 
average sellers for a particular 
[DEFINE TIME PERIOD: eg "day"] 
over [DEFINE HISTORICAL 
PERIOD eg "Iast4 weeks"] 






E02 




Prices in my 
market (s) are 
rising 


....prices in my area rising above 
[SELECT PERCENTAGE] in the 
last [DEFINE TIME PERIOD eg 
"hour"] compared to prices in the 
period [DEFiNE HISTORICAL 
PERIOD eg: week"] 






EOS 




Extend my area 
of willingness to 
sell in line with 
demand 


....utilization within [SELECT 
DISTANCE] of [SELECT 
POSTALCODE] fells below 
[SELECT PERCENTAGE] I will sell 
there [AS WELL or INSTEAD] 


This rule only 
applies if 
.utilisation in my 
defined selling 
area is above 
[SELECT 
PERCENTAGE] 


Verification: only 
one of geography 
dependant rules 
(eg: P08, E03 and 
M03) can be in 
force at any time. 
They can not be 
combined. 


E04 




Patterns in other 
markets 


...Ihe number of purchases in my 
defined market rise more than 
[SELECT PERCENTAGE] over 
[DEFINE TIME PERIOD] compared 
to [DEFINE HISTORICAL PERIOD] 


Offer Screen 
illustrated by Fig 
1 to allow user to 
define parameters 
of sales to which 
this rule is to 
apply, (eg "travel 
to specified 
location) 




EOS 




Events outside 
the markets 


. . the record for [SELECT 
VARIABLE] showing that at ihe time 
of purchase [SELECT FACTOR] 






E06 




My location 


....the work/ sale is immediate and 
within [SELECT FIGURE] of miles 
of my location as read from my 
[SELECT DEVICE] 




During-availability 
sweep triggered by 
this rule: location is ' 
updated in 
Availability Diary 
constantly while rule 
is in force 


F01 


Making a 
sale on 
time 


I want my 
offering re-sold if 
there is 
insufficient 
buyers 


....the number of units sold is below 
[SELECT NUMBER] within 
[DEFINE NUMBER OF HOURS] of 
the availability [CHOSE PERIOD eg 
"day"] beginning 1 wish to resell my 
offering providing I can obtain 
[SELECT PERCENTAGE] of ihe 
total value within [DEFiNE TIME 
PERIOD] 




Advance sweep 
triggered by this 
rule: sales record in 
TRANSACTION 
DATABASE 433 is 
checked at the time 
specified. 

Verification: Only 
one deadline 
specific rule, eg 
F01/F02 can be 
applied to a period 
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F02 




! want my 
offering 
unbundled if 
there is no buyer 
for the bundle 


i have not made a sale within 
[DEFINE NUMBER OF HOURS] of 
the availability [CHOSE PERIOD eg 
"day"] beginning I wish to break my 
offering up as specified. 


Offer screen 
represented by 
Fig 1 which 
allows seller to 
offer components 
of their previous 
offering 
individually. 


System monitoring 
triggered by this 
rule: sales record in 
TRANSACTION 
DATABASE 433 is 
checked at the time 
specified. If there 
are outstanding 
sales ihey are 
withdrawn and the 
unbundled version 
entered onto 
SELLER 
DATABASE 431 

Verification: Only 
one deadline 
specific rule, eg 
F01/F02 can be 
applied to a period 
of availability. 


F03 




I want ta change 
my 

availability/pricing 
rule if! have not 
had a purchase 
by a certain time 


, . . . I have not made a sale within 
[DEFINE NUMBER OF HOURS] 
[BEFORE or AFTER THE START 
OF] the availability [CHOSE 
PERIOD eg "day"] beginning I wish 
to change my availability to 
[SELECT RULE] 


Requires at least 
one other rule be 
stored for this 
user 


System monitoring 
triggered by this 
rule: sales record in 
TRANSACTION 
DATABASE 433 is 
checked at the time 
specified. If there is 
no sale, availability 
for the PERIOD 
SELECTED within 
ENHANCED 
AVAILABILITY 
STORE 560 is 
changed to the new 
rule 


D01 


A decision 
[ will make 
nearer the 
" time 


Availability I want 
to store 
provisionally 


...... 




Display ail 
availability under 
this rule faintly until 
it is confirmed. 
Display "confirm this 
availability" button. 


D02 




If! am 
contactable 


i have been active on my 

[DEFINE DEVICE] in the last 
[DEFINE TIME PERIOD eg: "5 
minutes"] . This applies only to 
immediate jobs. Or: My cell phone 
has been returning a signal 




May be determined 
by a during- 
availability sweep 
with current 
contaciability 
recorded in 
availability diary 


DOS 




A conversation 
with the buyer 


....a buyer has contacted me by 
[SELECT CONTACT METHODS 
TO BE RELEASED TO BUYERS] 
more fian [SELECT NUMBER] of 
hours before the period of 
availability and I have agreed to be 
available. 







i - ■ i 
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Actions at time of potential purchase (or times of sweep) 


RULE 
BEING 
ENACTED 


Column A 


Column B 


Column C 


Column D 


Column E 


Data source(s) 


Data to be extracted 


Calculation 


Availability is 
dependant 
on... 


Mandatory follow 
up action 


CP01 


ADDITIONAL 
PARAMETER 
RECORDS STORED 
IN SELLER 
DATABASE 
EXTENSIONS 


Seller's relevant para meters 


Does the 
present sale's 
parameters fell 
within the 
permissible 
parameters set 
by the seller? 


Parameters of 
the sale felling 
Within the 
seller's 
parameters 




P01 


TRANSACTION FILE 


Buyer identity 




A match with 
selection made 
in Column C 




P02 


TRANSACTION FILE 


Agency identity 




A match with 
selection made 
in Column C 




P03 


TRANSACTION FILE 
BUYER DATABASE 
432 


Buyer's current Grade 

< 




Buyer grade 
matches or 
exceeds C 
column input 




P04 


TRANSACTION FILE 
BUYER DATABASE 
432 


Buyer's profile 




The profile 
options input in 
C column match 
those in Buyer's 
profile 




P05 


SELLER 
AVAILABILITY 
RECORD 431B for 
named seller(s) 


Availability for the oeriod 
covered by this purchase 




Othpr ^ellpr (^\ 
required by 
entry in column 
C being i 
available 


Prpcpn f op ||pre a q 

a linked purchase 
on screen - if one 
is bought they 
must be all must 
be bought 


P06 


SELLER 
AVAILABILITY 
RECORD 431 B for 
named sellerfs^ 


Availability for the period 
covered by this purchase 




Other seller (s) 
required by 
entry in column 
C hpino 

available ; 


As above but the 
dominant seller is 
displayed 
nrnmin pnilv 

Lf) Ul J II J 1 CI 1 UY 


POT 


Trigger Asembly of 
Options Module 424 


Cheapest available seller 
within parameters defined in 
by user. 




The subsidiary 
purchase(s) 
being available 
and being 
reserved until it 
is clear whether 
this option will 
be purchased by 
the buyer 


Build price of • 
(subsidiary 
purchase(s) into 
offer price to 
buyer if that is 
user's choice 


P08 


TRANSACTION FILE 

SELLER 
PARAMETERS 
RECORD 431A 

TRANSACTION 
DATABASE 433 


(a) end location of the 
transaction 

(b) seller's current base 
postal code 

(C) number of historic 
transactions per SELECTED 
TIMEFRAME at the day/time 
of boo king from (a) to (b) 




The figure 
matching or 
exceeding the 
input in column 
G. 





Fig 7 
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P09 


TRANSACTION FILE 
SELLER 
AVAILABILITY 
RECORD 431B- this 
seller 


(a) blocks of units required 
for this purchase ■ 

(b) this seller's standard 
availability for the days 
covered by above 


What 

percentage of 
(a) can be met 
by (b)? 


The figure 
matching or 
exceeding the 
input in Column 
C 




P10 


TRANSACTION FILE 
SELLER 
AVAILABILITY 
RECORD 431 B - this 
seller 


(a) number of units required 
for each SELECTED 
TIMEFRAME of purchase 

(b) number of units this seller 
is showing availability for 
SELECTED TIMEFRAME of 
this purchase 


(a) as a 
percentage of 

(b) for each 
SELECTED 
TIMEFRAME 


Percentage 
does not exceed 
figure selected 
in Column C for 
any SELECTED 
TIMEFRAME 




P11 


TRANSACTION FILE 
SELLER 
AVAILABILITY 
RECORD 431 B- 
othef seller 


Is the other seller available 
but has no sales at the time 
of the sale? 




Other seller 
available having 
no sales 


If required: 
remove other 
seller's availability 
for duration of sale 


P12 


TRANSACTION FILE 

Seller Database 
Extensions DXB 


(a) voucher code input by 
buyer 

(b) voucher codes stored 
against this seller' 

(c) is voucher valid? 




Presented 
voucher still 
being valid. 
A match 
between codes 


Record use of 
voucher in seller 
records 


M01 


Seiler(s) 1 accounts 
page(s) 


Amounteamed in period 
defined in column C 




Amount being 
less/ more than 
amount defined 
in column C 




win'? 


Seller(s)' accounts 
page(s) 


Units sold in period defined 
in column C 




Amount being 
less/more than 
amount defined 
in column C 




M03 


None 


None 


None 




Reset seller's 
base postalcode 
to thatatend of 
each transaction 
for the specified 
period after sale. 


M04 


TRANSACTION 
DATABASE 433 


This seller's record of sales 
in the DEFINED TIME 
PERIOD 


Have required 
sales been 
made? 


Required sales 
not having been 
made. 




E01 


TRANSACTION 
DATABASE 433 
TRANSACTION FILE 


(a) number of sellers who 
were purchased per 
DEFINED TIME PERIOD in 
the DEFINED HISTORICAL 
PERIOD 

(b) number of sellers 
available for the present 
transaction 


-'(b)*asa - 
percentage of 
(a) 


Resulting 
percentage 
matching or 
exceeding the 
figure selected 
in column C. 




E02 


TRANSACTION 
DATABASE 433 


(a) seller's unitpriceson all 
purchases in the 
area/market sector(s) in 
which this seller is willing to 
sell averaged over the 
DEFINED TIME-PERIOD 

(b) seller's unit prices in 
same area/sector(s) 
averaged over the DEFINED 
TIME PERIOD 


(b) as a 
percentage of 
(a) 


Resulting 
percentage 
exceeding input 
in column C. 





Fig 7. (cont.) 
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E03 


TRANSACTION 
DATABASE 433 


(a) number of currently 
available for immediate work 
but unsold sellers in area 
defined in column c 

(b) number of sellers 
currently sold in above area 
(C) number of currently 
available for immediate work 
but unsold sellers in area 

UfcSliMcll HI LAjlUllin u 

(d) number of sellers 
currently sold in above area 


(b) as a 
percentage of 
(a) 

(d) as a 
percentage of 
(C) 


First figure is 
below the input 
in column c and 
second figure is 
above input in 
column d 




E04 


TRANSACTION 
DATABASE 433 


(a) number of purchases in 

rlpfinpr! markpf/ arpa n\/pr 
HISTORICAL PERIOD 

(b) number of purchases in 
defined market/ a rea over 
DEFINED TIME PERIOD 


(b) as a 

pel LA3-I 1 Idy C- Ul 

(a) 


Percentage 

pypppHinn in nut 

in column C. 




E05 


EXTERNAL 
VARIABLES 
DATASTORE 570 


Record for the SELECTED 
VARIABLE 




Is the 

SELECTED 
FACTOR a 
positive record? 




E06 


PI IDDCMT 

LOCATION 
INFORMATION 

TRANSACTION FILE 

SELLER 
PARAMETERS 
RECORD 431a 


(a) location of seller 

(b) location required for 
delivery of service 

(C) seller's maximum travel 
distance from base 
posialcode 


Distance from 
(a)to(b) 


(C) being equal 
to or less than 
figure produced 
by calculation 




ru i 


1 KAInoAU 1 IU!\ 

DATABASE 433 (for 
prices charged) 


move soiu units inio 
SELLER DATABASE 431 
from DEFINED NUMBER OF 
HOURS before purchase 
commencement until 
DEFINED TIME PERIOD 
has elapsed. Price at 
SELECTED PERCENTAGE 
of total value. 






onow tne ouyer 
this offering may 
be resold to 
another seller 


FU2 


This rule does not produce availability but creates a change of offering to be applied to SELLER DATABASE 431. 


F03 


This rule does not produce availability but creates a change of offering to be applied to SELLER DATABASE 431.. 


D01 


Availability in this rule is stored but ignored until it is confirmed (ie turned into a different rule) 


D02 


Seller Database 
Extensions DXB 
Seller Monitoring 
Module 540 


Is this an advance booking? 
Has user specified this rule 
apply to advance bookings? 
Is user currently 
contactable? 


Are advance 
booking s 
requirements 
met? 


Contaciability 

established 

Advance 

requirements 

met 




D03 


Seller Database 
Extensions DXB 

-SELLER DATABASE 
431 


Period of time before 
availability in which details 
may be released 

Seller contact details 


Is time of 
enquiry within 
the seller's 
permissible time 
before 
availability? 


Enquiry is within 
permissible time 


Details made 
available to buyer 
for offline 

conversation . - 



Fig 8. 
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802a 



\ 



802b 



\ 



802c 



\ 



804a 



804b 



806 



\ 



\ 



\ 



CREATE YOUR RULE 



My willingness to sell at the defined times 
is dependent on: 



<select> 



Particularly: 



<select> 



Under this rule I am only available to sell if: 



The purchase is by one of the following 
buyers: 



<seiect buyer> T | 



Under this rule my pricing is: 



<as normal> 



Under this rule my selling parameters are: 



<as norma!> 



My name for this rule is: 
I 



ACTIONS TO BE APPLIED WHEN 
YOU SELL UNDER THIS RULE 



If I make a sale under this rule, apply the 
following changes to my records: 

O Cancel my availab ility 

O Change to rule | <x> [ ▼! 



/ 



for a period of | <Q> | T [ hours 



Change my pricing for future transactions 
to: 



| <raise> 



by <0%> 



for a period of <0> 



hours 



Make my contactability procedure: 
<standard> [ ▼""] 



for a period of I <0> | T | hours 



Make my acceptance procedure: 
| <standard> | f] 



for a period of | <0> | T~| hours 



810a 



/ 



810b 



/ 



810c 



/ 



81 Od 



SUBMIT |' 



/ 



8-12 
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Fig 9. 
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Persona! 
rule no. 


E d 
o> = 

CO CD 

w 5 


Data 
check 1 


Data 
check 2 


Data ' 
check 3 


ACTION 


Sweep 
point 


User's 
name for 
rule 


1 ' 


P11 


bnj673fh 










Si ip ha<? not not a ioh and 
can look after the children 


2 


E01 


<80% 


24 hours 


12 weeks 




Throughout 
availability 


There's a shortage of taxis 
in town 


3 


or u i 


This user's 
Parameters 
version: 06 










Work around the middle of 
town only - no short notice 
bookings -extra 15% 


4 


M01 


7 days 


<$150 








I've cleared less than $150 
this week 


5 


EOS 


Meteorologic 
all 

Birmingham 
"Rain" 








Throughout 
availability 


It's raining in Central 
Birmingham 


6 


E05 


Meteorologic 

al/ ^ 
Birmingham 
"Rain" 






Automat 
ed call to 
ceil 
phone 


Throughout 
availability 


It's raining in Birmingham, 
Sue not working, I've made 
less than $150 this week. 
System will ring me. 




P11 


User: 
bnj6731h 










M01 


7 days 


<$150 










7 


F03 


This user's 
Parameters 
version: 03 








1 hour 
before 
availability 


If not sold by one hour 
before then drop price, 
enlarge distance. 


8 ; 


M01 


7 days 


<$180 








I've made less than $180 
this week 



Fig 10 
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MY AVAILABILITY RULES 



I am only available If... 

My rule 1 ...Sue has not got a job and can look after the children 

Mv rule 2 ...there's a shortage of taxi's in town 

My rule 3 ...work around the middle of town only - no short notice bookings - extra 15% 

My rule 4 ...I've cleared less than $150 this week 

My rule 5 ...it's raining in Central Birmingham 

My rule 6 ...it's raining in Birmingham, Sue not working, I've made less than $150 this week, system 
calls to check first 

My rule 7 ...if not sold by one hour before then drop price, enlarge distance. 

My rule 8 ...I've made less than $180 this week 



Create new rule : 
[ ] from scratch 



[ ] by modifying an existing rule [ ] by combining existing rules 



\ 



1004a- 



\ 



1004b- 



\ 1 



004c- 



MY PERIODS OF AVAILABILITY 



Displaying: week beginning: | <14 tn April> | T~j 

—1006a- 



1006b \^ 
Max daily periods of availability | <2> | 



MO 


Start: 




End: 




Avail a unity; 




Start: 




End: Availability: 






| <00.00> | 




| <00.00> 


I T 


<standard> 


M 


\ <00.00> 


| T 


| <00.00> | T | <standard> 


M 


TU 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 


▼ 


| <00.00> 


T 


<standard> 


M 


| <00.00> 


| T 


| <00.00> | T | <standard> 


M 


WE 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 


T 


| <00.00> 


T 


<standard> 


M 


| <00.00> 


| T 


| <00.00> | T | <standard> 


M 


TH 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 


▼ 


| <op.oo> 


T 


<standard> 


M 


| <00.00> 


| T 


| <00.00> | T | <standard> 


M 


FR 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 


▼ 


| <00.00> 


I ▼ ] 


<standard> 




| <00.00> 


| T 


| <00.00> | T | <standard> 




SA 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 




| <00.00> 


▼ | 


<standard> 


M 


| <00.00> 


| T 


| <00.00> | T | <standard> 


!▼! 


su 


Start: 




End: 




Availability: 




Start: 




End: Availability: 






| <00.00> | 


▼ 


I <00.00> | 


T | 


<standard> 


M 


| <00.00> 


T 


| <00.00> | T | <standard> 





/ 



1002 



/ 



1004 



/ 



/ 



1006 



1008 



/ 



1012 



1014 



Capture this as my usual availability 
Apply my usual availability 



Click for sales in this period 



1010 



SUBMIT 



/ 
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Build table of periods 

— I 



Fig 12. 
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Search first 
unsearched period 



/ 
/ 



1202 



1204 



Read first 
unsearched rule 



/ 



Access data 
source(s) 



/ 



1206 



1208 



Extract required data 

— I ' 



/ 



Perform calculation 
(if required) 

i 



/ 



1210 



1212 



Read availability 
requirements 



/ 



1214 




Apply mandatory 

actions to 
Transartion File 



/ 



Apply user's actions 
to Transaction File 



/ 



1222 



1224 



Offer seller to buyer 



/ 



1226 




Apply all actions in 
Transaction File 



1230 



-►C ENDS J 



Exclude seller from 
options offered 



/ 



1232 




ENDS 



Fig 13 
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Transaction No.: 



1302 
1304 



J 1306 


J 1308 


J 1310 


J 1312 


^ 1314 


J 1316 


Availability 
Period No. 


Times 
Covered 


Rule 
governing 
availability 


Available? 


Unit price for 
this period 


No. of units 
covered 


1 






Y/N j 






2 






Y/N 






3 






Y/N 







Fig 14. 



Dis play transactions covered by: 

Markets 
Availability rules 



<all> 


▼ 


<all> 


▼ 



/ 



1402 

Display 
within 
between 



<all> 


T 


<all> 


T 


<select date> 


▼ 



times of day / 
days of the week 
and | <today> I T I 



1404 



cheapest 



2 nd cheapest 



3 rd cheapest 



4 th cheapest 



Below 4 th 
cheapest 



\ 



1408 



/ 



1406 




1410 



Av. unit price 
displayed 



$9.37 



% availability 
cheapest 

1412a 



28 



% availability 
sold 



37 



1412b 



14-12e- 



